profiling dynamically linked executables

[eLiu]

Hi all,
How can you profile a dynamically linked application? I have limited experience using gprof, but only with statically linked programs. Doing the same procedure with this dynamically linked app is not satisfactory b/c it doesn't detect any of the dynamically linked functions.

I'm hoping the answer is not "switch to static linking" b/c to be honest I don't know how to do that. The application is pretty big, was written by many people, and the dynamic libraries are part of the code design. (It solves PDEs; we use dynamic linking to do things like load a certain type of equation set at run-time.)

I have access to the gnu compilers & the intel compilers. Intel has that "pgo" framework, but I don't know how to view the .dyn files instead of feeding them to the compiler for automatic optimization. Also I don't currently have VTune but I can get it.

-Eric

 

[Cogman]

if you don't have access to the libraries source, then you are sol. If you do have access to it, then compiling the libraries with the -pg option should show profile data on the linked libraries.

Of course, that does depend on HOW you are linking the libraries. If it is the header/function call method, then the above should work fine. However, if you are doing some call to the OS to get a function from a dynamic file, then I believe you are sol.

I would have thought that profiling just the regular program would have still fingered out how much time is being spent on your dynamic libraries. (IE "We spent x amount of time on this function call which just happens to be in your dynamic library") Provided, it wouldn't give you specific information about what is actually going on in the library when you profile it.

 

[eLiu]

Nope... the functions from the dynamic libraries are just completely missing from gprof output. The sum of all the times is also inconsistent with how long it actually takes. gprof documentation also indicates that it can't deal with dynamically linked executables.

I'm looking into how to reconfigure the thing to compile with static linking. Hopefully the guy who set up our makefile system knows how.

 

[degibson]

You could flank all the calls into your libraries with calls to rdtsc, and just measure the total time spent inside the library. Admittedly, it doesn't help to do performance debugging on the library itself...

 

[eLiu]

Originally posted by: degibson
You could flank all the calls into your libraries with calls to rdtsc, and just measure the total time spent inside the library. Admittedly, it doesn't help to do performance debugging on the library itself...

This is far far more work than figuring out static linking... which with some help, I've managed to do.

So thanks all, and in the future I'll keep in mind that dynamic linking is a no-no for profiling

 

[degibson]

Originally posted by: eLiu

Originally posted by: degibson
You could flank all the calls into your libraries with calls to rdtsc, and just measure the total time spent inside the library. Admittedly, it doesn't help to do performance debugging on the library itself...

This is far far more work than figuring out static linking... which with some help, I've managed to do.

So thanks all, and in the future I'll keep in mind that dynamic linking is a no-no for profiling

Oh, for some reason I thought you didn't have library source... re-reading your post makes more sense now.