This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


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

Re: [RFA] patch to add 'maint profile-gdb' command


On Tue, Sep 11, 2001 at 09:39:16AM +0200, Eli Zaretskii wrote:

> > monstartup provides some information, but not everything that full
> > profiling gets you.
> 
> Sorry, I don't understand what you mean.  AFAIK, a program linked with
> "-pg" calls monstartup in its startup code.  

No, there is a lot more to a profiled program than that.  The
compiler adds instrumentation in the code, sometimes simple calls
to mcount, sometimes more than that.  It'll link in different
startup files (e.g. "gcrt1", "gcrtend"), and different versions of
libc (e.g. "c_p"), as well as the "gmon" library on some systems.
A simple call to monstartup() won't do that.  The man page on a
FreeBSD system for monstartup() includes this text:

     Programs that are not loaded with -pg may selectively collect profiling
     statistics by calling monstartup() with the range of addresses to be pro-
     filed.  
[...]
     Only functions in that range that have been compiled with the -pg
     option to cc(1) will appear in the call graph part of the output; howev-
     er, all functions in that address range will have their execution time
     measured.  

Calling monstartup() will get you the timing information, but not
the call graph information on a FreeBSD system, apparently.  On a
Linux system, calling monstartup() doesn't get you anything unless
you compile with -pg.


The point of this is that profiling is a compile-time decision.
If you're not compiling for profiling, then there's little reason to
include calls to the profiling control functions.  

I know it seems strange to ifdef the call to moncontrol() like
Tom's patch does, but I don't see any gain to using an autoconf
conditional -- the moncontrol() call is only going to work when
you're compiling specifically for profiling.  

Think about how the code would look.  A test to see if moncontrol()
works without -pg is not useful -- if we're on a system where
moncontrol() doesn't work without -pg, then we wouldn't set
HAVE_MONCONTROL (or whatever the macro setting is), but we _would_
be compiling -pg so we _would_ have moncontrol().  If we're adding a
test to see if moncontrol is available when -pg are used, then we
couldn't use the results of that in a non-pg gdb.  The code which reads

#ifdef ENABLE_PROFILE
    moncontrol (0);
#endif

Would now read

#ifdef ENABLE_PROFILE
#ifdef HAVE_MONCONTROL
    moncontrol (0);
#endif
#endif

Unless we find some system which has profiling but doesn't have
moncontrol(), I don't see any benefit to using autoconf to detect
this.

Jason


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