Profiling a shared library called by vendor code

Profiling a shared library called by vendor code

Post by Clint Olse » Sat, 17 May 2003 06:27:14



We have some code which is compiled into a shared object and then loaded by
a vendor application using dlopen().  Unfortunately, profiling data is not
generated in this case, and even if it did, gprof is unable to discern the
information anyway.

Is there any way to accomplish this?

Thanks,

-Clint

 
 
 

Profiling a shared library called by vendor code

Post by M?ns Rullg? » Sat, 17 May 2003 07:06:17



> We have some code which is compiled into a shared object and then loaded by
> a vendor application using dlopen().  Unfortunately, profiling data is not
> generated in this case, and even if it did, gprof is unable to discern the
> information anyway.

> Is there any way to accomplish this?

Write a simple test application that links to this library and profile
that.

--
M?ns Rullg?rd


 
 
 

Profiling a shared library called by vendor code

Post by Clint Olse » Sat, 17 May 2003 07:32:37



> Write a simple test application that links to this library and profile
> that.

That can't be done.  The library itself calls symbols that are only
provided by the vendor application.  In other words, the library is only
able to run _with_ the application which loads it.

-Clint

 
 
 

Profiling a shared library called by vendor code

Post by M?ns Rullg? » Sat, 17 May 2003 08:38:24



> > Write a simple test application that links to this library and profile
> > that.

> That can't be done.  The library itself calls symbols that are only
> provided by the vendor application.  In other words, the library is only
> able to run _with_ the application which loads it.

Provide stubs for those.  Does the library execution depend on return
values from these functions?  In that case you could let your dummy
functions return typical values.  Being more extreme, you could run
the real program once and record the return values of its functions.
Then return those values in the same order when profiling.

What does the program do?  What does your plugin do?

--
M?ns Rullg?rd

 
 
 

Profiling a shared library called by vendor code

Post by Grant Taylo » Sat, 17 May 2003 12:08:18



> We have some code which is compiled into a shared object and then
> loaded by a vendor application using dlopen().  Unfortunately,
> profiling data is not generated in this case, and even if it did,
> gprof is unable to discern the information anyway.
> Is there any way to accomplish this?

You can use a sampling profiler instead of a graph profiler.

man setitimer and sigaction.  Then write a signal handler for SIGPROF,
and inside it do something with the program counter value reported by
the OS, like write it to a file or pipe.  You can optionally unwind
the stack a frame or two, although depending on platform this may be
difficult or impossible.

Alternatively, some C libraries have support for doing the above in
the form of profil(3).  I just find it more informative to gather raw
samples and postprocess.

Once you have the samples, you need to determine how your shared
objects were linked, usually this is just a bit of offset math against
some dlsym results, ldd output, or the likes of /proc/maps plus the
result of nm on the shared objects that make up your exe.  Correlate
this map data with the samples, and that's that.

There's a fellow out there with an inexpensive commercial
implementation of the above.  Perhaps he'll pop up and save you an
afternoon of tinkering.  For that matter, perhaps there's a free tool
floating around by now.

--
Grant Taylor - gtaylor<at>picante.com - http://www.picante.com/~gtaylor/
   Linux Printing Website and HOWTO:  http://www.linuxprinting.org/

 
 
 

Profiling a shared library called by vendor code

Post by Paul Pluzhniko » Sat, 17 May 2003 13:05:33



> We have some code which is compiled into a shared object and then loaded by
> a vendor application using dlopen(). [...]

> Is there any way to accomplish this?

On what platform?

On Linux, take a look at http://www.bitwagon.com/tsprof.html
On Irix, "man pixie".

Elsewhere, I don't know of a way.


> > > Write a simple test application that links to this library and profile
> > > that.
> > That can't be done.  The library itself calls symbols that are only
> > provided by the vendor application.

> Provide stubs for those.  Does the library execution depend on return
> values from these functions? [...]

It doesn't matter. This approach to profiling will result in data
that is almost guaranteed to have nothing to do with the *real*
application profile. Accurate profiling is hard enough without fudging ;-(

Cheers,
--
In order to understand recursion you must first understand recursion.

 
 
 

Profiling a shared library called by vendor code

Post by Clint Olse » Sat, 17 May 2003 13:32:04



> Provide stubs for those.  Does the library execution depend on return
> values from these functions?  In that case you could let your dummy
> functions return typical values.  Being more extreme, you could run the
> real program once and record the return values of its functions.  Then
> return those values in the same order when profiling.

> What does the program do?  What does your plugin do?

It interfaces to a simulator.  Just about every call to these library
functions returns or sets a value, so what you're describing sounds
prohibitive.  There is a messy way a co-worker suggested to work around it,
but it requires manually calling the profiling routines for a range of
addresses at the beginning of execution and then atexit().  It also
requires a hacked version of gprof as well.  Bleah...

Thanks,

-Clint

 
 
 

Profiling a shared library called by vendor code

Post by Valentin Nechaye » Sat, 17 May 2003 15:16:19


GT> Alternatively, some C libraries have support for doing the above in
GT> the form of profil(3).  I just find it more informative to gather raw
GT> samples and postprocess.

Moreover, profil(2) FreeBSD manpage says:

HISTORY
     A profil() function call appeared in Version 7 AT&T UNIX.

Unless it was excluded from particular system (why?), it is available.

GT> Once you have the samples, you need to determine how your shared
GT> objects were linked, usually this is just a bit of offset math against
GT> some dlsym results, ldd output, or the likes of /proc/maps plus the
GT> result of nm on the shared objects that make up your exe.  Correlate
GT> this map data with the samples, and that's that.

Or better call dlsym() in runtime and print addresses in debug output
in program-parseable form.

-netch-

 
 
 

Profiling a shared library called by vendor code

Post by Chris Sheppar » Sat, 24 May 2003 08:03:30




>>We have some code which is compiled into a shared object and then loaded by
>>a vendor application using dlopen(). [...]

>>Is there any way to accomplish this?

> On what platform?

> On Linux, take a look at http://www.bitwagon.com/tsprof.html
> On Irix, "man pixie".

> Elsewhere, I don't know of a way.

I couldn't get the bitwagon site to work; however, I've been looking
(shallowly; haven't seriously tried it yet) at oprofile:
http://oprofile.sourceforge.net/
It uses a kernel module to do the timing. (not surprisingly, I believe
it only works on Linux at present)  It might help you.

Chris

 
 
 

1. Making shared libraries from vendor libraries

I recall a few years ago reading about a method to convert vendor libraries
into shared libraries.  I think it involved disassembling the objects in the
library and doing some "sed" type things to it and then reassembling with
proper options to allow linkage into a shared library.  However, I don't
remember the details.

I am particularly interested in convering Oracle's libraries into shared
libraries.  Has anyone out there done this on Solaris 2.3?  (I'm also
interested in SunOS 4.1.x and Solaris 2.4 if its a different procedure).
If so any tips you can provide or scripts you've used to successfully do this
would help me a great deal.  Please send any information to me via e-mail
since our news feed can be a bit flakey.

thanks,
dave

or

2. Serial I/O error

3. Profiling tools that work with shared libraries

4. Xconfig for wd903c0-LR _almost_ works

5. Profiling a shared library

6. NAT and Firewall

7. profiling shared libraries

8. sed adressproblem

9. Will strip(debug shared library) == nodebug shared library ?

10. Help with building shared libraries with dependencies on other shared libraries

11. Question: Inclusion of shared libraries during linking of shared libraries

12. Shared library loading shared library.

13. Need a Shared Library Guru: beyond simple shared library question