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

["Eli Zaretskii" <eliz@is.elta.co.il>]

> Date: Wed, 12 Sep 2001 07:41:41 -0700
> From: Jason Molenda <jason-swarelist@molenda.com>
> 
> Don't you think we're going to get real portability headaches this
> way? In some cases the mcount et al functions are provided by the
> compiler, in some they might be in libc, in some they might be in
> a profiling version of libc or in a separate gmon library altogether.
> 
> I think the gprof designers on all the systems out there would assume
> that if you're compiling with -pg, you're linking with -pg.  Doing
> it differently could easily mess up their assumptions.

I think that a system which has monstartup should support the method I
described.  Otherwise, monstartup doesn't make much sense.

> All of this with monstartup() is only to avoid overwriting the
> gmon.out file whenever you start a profiling gdb.

I'm mostly worried about getting noise into the profile, due to
profiling that starts as soon as GDB starts running, until you turn it
off with moncontrol.  That noise might hide interesting details, and
might trick a developer to dismiss important findings as noise.

> If we were to add these monstartup() calls, we'd also have the
> portability problems that I mentioned earlier.  Not all systems
> that provide profiling and moncontrol() provide the monstartup()
> call.  So we'd need an autoconf test to detect that, and we'd define
> LD_FLAGS and a C preprocessor macros depending on the results of
> that test.  And the documentation for all of this would be confusing.
> "Your gmon.out file will be overwritten each time you execute gdb,
> unless your system provides the monstartup() system call."

Somehow, I don't see these problems to be as grave as you do ;-)

I think the benefits justify this.  But that's just me...