John Levon wrote:
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
As I know about Eclipse Oprofile Plug-in, yes, it does have some methods to
converting file offset to meaningful symbol+offset info, but, they are not
complete and correct (Please correct me if I am wrong). For example,
it lacks handling of opd_header.anon_start to set a correct start_offset value,
and it lacks sufficient ppc64 support of synthesizing ppc64 target's symbols table.
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 or ppc64
architecture specifics. And I really appreciate if oprofile can hide these things
in background from users or tool developers.

As what APIs oprofile could/should export, I feel three categories API are usful,

1. low-level API, the API to get the configuration environment of oprofile,
and to get raw profiling data from oprofile sample files, now it is mainly located
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
    files hierarchy. 
    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 library to
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
                            source lines
        process ...
    session ...
        ... ...
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 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