RE: RFC: Profiling multiple DSOs

["Ken Whaley" <ken at believe dot com>]

> > Here is a patch to support profiling multiple DSOs. It works with
>
> HJ, I don't want to complicate ld.so for some solution which is not
> fixing the problems completely.  Debugging multiple DSOs without
> debugging the application code is not useful.

It's certainly less useful, but useful nonetheless when zero
alternatives exist today to profile a complete application
together with the DSOs it's linked against.

> Better said, this is
> not problem people want to see solved.
>

Are you saying you think people don't want to be able to profile an
application together with the DSOs it's linked against?  I strongly
disagree.  I would *love* to be able to profile my application
together with the DSOs it's linked against.  We have an in-house
application that's linked against DSOs, where a great deal of the
work happens in the DSOs, so profiling them all together with the
application is essential.    Since glibc/gprof doesn't provide this,
we had to do our profiling on the solaris workbench and on
alpha-linux+iprobe.   I don't consider these satisfactory solutions
since: solaris workbench costs $$$, and so do alphas, and neither
are portable techniques.

There are many usenet messages about people asking
"why doesn't gprof profile the DSOs together with the
application on linux?"  The desire is absolutely there for users.

In order for this to work, I'd think it'd take just a couple
of things: the ability to register a callback (or some other
mechanism) with the dl code to signal when a new range of code
address space is added to the process (which would work both for
dynamic linking and explicit dlopen()), and changing the mcount code
to deal with (say) a linked list of address space buckets, and a
small change to the gmon.out data structure to include the path
of the DSO that corresponds to an address range so that function
names can be correctly matched to PC samples.

I wouldn't mind working on something like this, but it would be
nice to know ahead of time whether an approach like this would
be accepted into glibc.

Ken