How do you profile an executable that loads shared libraries?

[Mike Frysinger]

On Monday 23 February 2009 03:54:02 Tristan Gingold wrote:
> On Feb 20, 2009, at 6:00 PM, Mike Frysinger wrote:
> > On Friday 20 February 2009 10:33:37 Nick Clifton wrote:
> >>> I have an executable that loads shared libraries. I compiled with
> >>> "-g
> >>> -pg" and then I ran gprof on the gmon.out file. I don't see any of
> >>> the
> >>> shared libraries that the program loaded in my gprof output. How do
> >>> you profile shared libraries?
> >>
> >> It seems that this is no longer possible. :-(  Perhaps you could try
> >> another profiling tool (eg oprofile) or else using static libraries.
> >
> > just curious, but how so ?  if the -pg code simply adds calls to
> > mcount at
> > every function entry, why would shared libs matter ?
>
> -pg not only adds calls to mcount but also enable the use of profil(2)
> (or SIGPROF).  This syscall
> makes kernek update counts in the samples buffer which represent one
> address ranges.  With shared libraries
> you have many addresses ranges.
> Some systems (such as Solaris) have an alternate method that works
> with shared libraries.

the kernel provides one virtually contiguous address range to each userspace 
program and each application/shared object gets a dedicated chunk of that.  so 
unless it's a matter of the profiling code not saving the address map so the 
addresses can be coordinated after the fact, i dont see how this would be an 
issue.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20090223/ec490cc7/attachment.sig>