This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How do you profile an executable that loads shared libraries?


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

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]