John Levon wrote:
As I know about Eclipse Oprofile Plug-in, yes, it does have some
On Fri, Dec 16, 2005 at 05:04:15PM -0600, Maynard Johnson wrote:
In fact, this first iteration of categorizing obd.h was done simply by
looking at what the Eclipse-OProfile plug-in uses. Of course, the
If Eclipse already has its own methods for converting a file offset to a
meaningful symbol+offset, then exporting this makes sense as a low-level
converting file offset to meaningful symbol+offset info, but, they are
complete and correct (Please correct me if I am wrong). For example,
it lacks handling of opd_header.anon_start to set a correct
and it lacks sufficient ppc64 support of synthesizing ppc64 target's
These two things are difficult for Eclipse plug-in developers to deal
with if they
have little knowledge of oprofile internal data structure, bfd library
architecture specifics. And I really appreciate if oprofile can hide
in background from users or tool developers.
As what APIs oprofile could/should export, I feel three categories API
1. low-level API, the API to get the configuration environment of
and to get raw profiling data from oprofile sample files, now it is
in directory libdb and libop.
a. Arch specifics,
CPU type, counters, events and counter_events_map.
b. OS related,
sample files directory, log file, etc.
c. oprofile's sample file layout and internal data structure
methods to create sample files list, to analyze sample file names,
to build the sample
methods to analyze sample file's data structure, such as header,
nodes table, hash table.
methods to get offset and counts list from sample file, user input
the file name, and
get the list of <offset, count> pair.
With these information, user can do whatever he likes, using bfd
get symbols, get source lines info, or disassemble binary code to see
the instruction details.
With the evolution of oprofile, this API is variable to some degree.
2. high-level API, the API to get post processing results, I see this
API as an abstract layer,
through this API, user can build a profiling hierarchy model and fetch
meaningful things from it.
With my little experience with oprofile and Eclipse Oprofile plug-in, I
think the following
profiling hierarchy model is to some degree complete and useful,
session (name, total <event,count> list)
process (name, pid, <event,count> list)
thread (tid, <event,count> list)
dep module (name, <event, count> list)
symbol (name, <event, count> list)
symbol binary codes
occoured sample offset
So, in order to build this profiling data model, the following methods
should provided by oprofile,
a. methods to get the CPU type, event, counter and its realtionship map.
b. methods to get sample offsets and count from sample files.
c. methods to wrapping BFD related opreations, such as retrieve symbol
table, binary contents and debug
info from object files.
3. utility API
When browsing OProfile source code, I find that some utility class
objects or functions are very useful
to developers, such as cverb for debug use, bfd support, string filter,
command option processing, etc.
This API can be a complementary API to the low-level API, developers
can use it or not.
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
oprofile-list mailing list