From: Suthikulpanit, S. <Sur...@am...> - 2008-12-15 17:45:33
|
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 |