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 Wed, Sep 12, 2001 at 03:56:46PM +0300, Eli Zaretskii wrote:

> No, I mean that a program _compiled_ with -pg, but linked _without_ -pg
> will not start profiling until it calls monstartup.  

Ah, OK.  I knew we were talking about different things somehow.

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.

All of this with monstartup() is only to avoid overwriting the
gmon.out file whenever you start a profiling gdb.  I don't think
it's worth the trouble.  A programmer who is compiling with
--enable-profiling is presumably clever enough to understand that
gmon.out must be moved aside if they don't want it overwritten.
Or he'll learn after the first time he has it overwritten.

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."




> I really don't see much point to
> > bothering wiith a check for moncontrol.  I suppose it means a gdb
> > developer who tries to enable profiling without the necessary
> > moncontrol() function will find out about his folly at configure-time
> > instead of link-time, but that's the only benefit I can see.
> 
> I think this benefit should not be disposed off too easily.  

OK, I'll add a check for moncontrol and repost the patch in the next day
or so.

J


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