[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oprofile-list
Subject:    Questions Regarding Export Oprofile Library Interface
From:       "Suthikulpanit, Suravee" <Suravee.Suthikulpanit () amd ! com>
Date:       2008-12-15 17:45:18
Message-ID: 9BCA02B0979C2A429C5965B8AE29269805DA7FD6 () SAUSEXMB2 ! amd ! com
[Download RAW message or body]

Hi,

I am wondering if anyone is currently working on exporting ABI/API for
Oprofile libraries, and also exporting them as shared libraries.  In the
past, I have noticed several discussion threads and the attempts to
cleanly export libraries for other tools to link to.

I am working on the CodeAnalyst tool, and planning to add CodeAnalyst as
part of Fedora distribution (targeting Fedora 11 and OpenSuSE 11.2).  We
are planning to distribute a package which will be depending on the
oprofile-devel package provided by the distribution. Currently, the
oprofile-devel package on Fedora contains the following files:

# rpm -ql oprofile-devel 
/usr/include/odb.h 
/usr/include/op_config.h 
/usr/include/op_cpu_type.h 
/usr/include/op_events.h 
/usr/include/op_list.h 
/usr/include/op_sample_file.h 
/usr/include/op_types.h 
/usr/lib64/libodb.a 
/usr/lib64/libop.a 
/usr/lib64/libopabi.a 
/usr/lib64/liboputil++.a 
/usr/lib64/liboputil.a

I am running into couple issues:

CodeAnalyst requires additional headers and libraries (libpp, libregex)
as following:

1. struct profile_t (libpp/profile.h) to process each oprofile sample
files.

2. parse_filename() (libpp/parse-filename.h) to parse oprofile sample
files filename.

3. class op_bfd (libutil++/op_bfd.h) to access binary files

4. demangle_java_symbol() (libregexp/demangle_java_symbol.h) to help
demangling java symbol puts out by java agent for jitted code.

As far as I know, OProfile does not currently have ABI for these two
libraries which handle processing sample files and demangling java
symbol. Are there any plans to export these libraries / functionalities?
(similar to the work done for libodb.a and odb.h) If not, would this be
in the consideration? 

Another question is with the current code build, Oprofile only outputs
static libraries.  Are there any plans on creating out shared libraries
so that other tools can easily link against?  With the current code, if
I try to change Makefile.am's to outputs shared libraries, I got the
following errors:

ERROR 1:
/sandbox/oprofile-FC11/oprofile-FC11-test/libregex/.libs/libop_regex.so:
undefined reference to `options::demangle'

ERROR 2:
/sandbox/oprofile-FC11/oprofile-FC11-test/libpp/.libs/libpp.so:
undefined reference to `classes'

The errors occur when other libraries trying to link to them.  These
objects are declared as extern in the libpp/libregex, and declared as
global object in pp/opreport_options.cpp and pp/opannotate_options.cpp.
It would require changes to several internal functions so that these
object being passed properly instead of using it in globally fashion.
Would this be something that Oprofile would like to see happening?

Thank you,

Suravee
 


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
[prev in list] [next in list] [prev in thread] [next in thread]