Re: Should GCC tell GDB about its optimizations?

[Stephane Carrez <Stephane.Carrez@worldnet.fr>]

Hi!

Stan Shebs wrote:
> I'm sure this subject has come up before, but I don't remember any
> consensus...
> 
> In the process of finishing Mac OS X, Apple has hundreds of engineers
> beating on GCC and GDB every day.  The system has literally hundreds
> of subcomponents; everything from the kernel to speech output to Hebrew
> font support (sort of like a Linux system preloaded with everything
> you can find on freshmeat :-) ).  By default, everything is built with
> optimization turned on.  While an engineer can turn off optimization
> for a specific bit of code, it's not practical to build an entire system
> with optimization turned off.  So in practice any single program consists
> of a combination of optimized and unoptimized code.
> 

We have some similar problem at Sun with ChorusOS. However, I've never
seen that mixing optimized/non optimized code was really the problem.
It was rather related to mixing debugging/non debugging code. May
be that's also the problem you are facing with (ie, compile some parts
with -g, some others without).

My understanding is that this makes debugging wrong because GDB 
is not able to find out what registers are saved in functions not compiled
with -g. I don't think this is related to optimization (also see
"Timothy J. Wood" <tjw@omnigroup.com> e-mail).


There is a notion of level of debugging info in GCC. I think it was
intended to emit only the minimal debugging info (such as frame layout
or things like that). In this case, the complete system should be built
with such minimal debugging info (frame layout). Some specific files
could be compiled with -g (full debug). 

This makes sense also for any library in general that you link with
(libc, ...). If such library is not compiled with -g, you cannot get
valid access to your local variables when you stop in some system call.
Now, if your function is compiled without optimization, gcc will not
allocate your local variables in registers, and GDB should be able
to give you good values for local variables.

This is my understanding of debugging with DWARF-2.

Anyway, it makes sense to know whether some files are compiled with
optimization or not.

	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France
From eliz@delorie.com Sat Mar 04 23:38:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sat, 04 Mar 2000 23:38:00 -0000
Message-id: <200003050737.CAA10121@indy.delorie.com>
References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <bem9u49sh.fsf@rtl.cygnus.com> <200003021007.FAA04124@indy.delorie.com> <38C0ACF2.C00719B0@cygnus.com>
X-SW-Source: 2000-03/msg00076.html
Content-length: 509

> Eli Zaretskii wrote:
> > 
> > > Well, if memory serves, if you re-ran configure in such a way that
> > > tm.h started linking to a different file, then the config.status
> > > dependency was the only way to force a rebuild.
> > 
> > How about adding some #define to config.h that would also change when
> > this happens?
> 
> Such as the names of the tm, xm and nm files?

Yes, that's what I had in mind.  Since the configure scripts already
knows the names of those files, it could put them into config.h.
From eliz@delorie.com Sun Mar 05 00:05:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: `long double' support for ix86 targets
Date: Sun, 05 Mar 2000 00:05:00 -0000
Message-id: <200003050805.DAA10149@indy.delorie.com>
References: <200003031531.e23FV8T00285@delius.kettenis.local>
X-SW-Source: 2000-03/msg00077.html
Content-length: 885

> I intend to check in the following patch in a week or two, but since
> this change affects most of the ix86 targets, I'd like to give people
> the opportunity to object.
> 
> Mark
> 
> 
> 2000-03-02  Mark Kettenis  <kettenis@gnu.org>
> 
> 	* config/i386/tm-i386.h (TARGET_LONG_DOUBLE_FORMAT): Define as
> 	&floatformat_i387_ext.
> 	(TARGET_LONG_DOUBLE_BITS): Define as 96.
> 	(REGISTER_VIRTUAL_TYPE): Change type for FPU registers to
> 	`builtin_type_long_double'.
> 	(REGISTER_CONVERT_TO_VIRTUAL): Simply copy over the data, and pad
> 	with zeroes.
> 	(REGISTER_CONVERT_TO_RAW): Simply copy over the significant data.
> 	(i387_to_double, double_to_i387): Remove prototypes.

These changes are okay for DJGPP.

Btw, shouldn't we also have identical definition for
HOST_LONG_DOUBLE_FORMAT for native debugging?  Several functions ask
about the host and target format being identical.
From eliz@delorie.com Sun Mar 05 00:36:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: COERCE_FLOAT_TO_DOUBLE
Date: Sun, 05 Mar 2000 00:36:00 -0000
Message-id: <200003050836.DAA10166@indy.delorie.com>
X-SW-Source: 2000-03/msg00078.html
Content-length: 428

The comments about COERCE_FLOAT_TO_DOUBLE in valops.c seem to suggest
that every modern architecture should define it to
standard_coerce_float_to_double.  I was about to add that definition
to tm-go32.h when I noticed that none of the other i386 targets,
including linux native, does that--they all use the default
definition.

Shouldn't most/all i386 targets, at least those which use GCC, use
standard_coerce_float_to_double?
From eliz@delorie.com Sun Mar 05 00:50:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Cc: ezannoni@cygnus.com
Subject: Buffering problems with "gdb < foo"
Date: Sun, 05 Mar 2000 00:50:00 -0000
Message-id: <200003050850.DAA10185@indy.delorie.com>
X-SW-Source: 2000-03/msg00079.html
Content-length: 1150

A comment in event-top.c (inside the change_line_handler function)
says this:

  /* NOTE: this operates on input_fd, not instream. If we are reading
     commands from a file, instream will point to the file. However in
     async mode, we always read commands from a file with editing
     off. This means that the 'set editing on/off' will have effect
     only on the interactive session. */

However, running "gdb < foo" seems to contradict this: I put a
breakpoint in gdb_readline2, and it is never hit.  Am I missing
something?

The problem with this is that if the file `foo' includes a command
which needs a confirmation, the call to fgetc in query will eatup lots
of characters which will never again be seen by the event loop.  In my
case, fgetc read all the file (it was small), so GDB hit EOF and
exited.  I can prevent this from happening by putting "set editing off"
in the input file.  Invoking GDB with --noasync also solves the
problem.

Does this work on Unix?  If so, it would make this a DJGPP-specific
problem.

If this is not DJGPP-specific, then I think _initialize_event_loop
should turn editing off if input_fd is not a tty.
From ac131313@cygnus.com Sun Mar 05 00:56:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sun, 05 Mar 2000 00:56:00 -0000
Message-id: <38C220BE.44922A6@cygnus.com>
References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <bem9u49sh.fsf@rtl.cygnus.com> <200003021007.FAA04124@indy.delorie.com> <38C0ACF2.C00719B0@cygnus.com> <200003050737.CAA10121@indy.delorie.com>
X-SW-Source: 2000-03/msg00080.html
Content-length: 1020

Eli Zaretskii wrote:
> 
> > Eli Zaretskii wrote:
> > >
> > > > Well, if memory serves, if you re-ran configure in such a way that
> > > > tm.h started linking to a different file, then the config.status
> > > > dependency was the only way to force a rebuild.
> > >
> > > How about adding some #define to config.h that would also change when
> > > this happens?
> >
> > Such as the names of the tm, xm and nm files?
> 
> Yes, that's what I had in mind.  Since the configure scripts already
> knows the names of those files, it could put them into config.h.

Well I've long had in mind a ``maint build-info'' command that printed
out things like:

	tm/xm/hm.h
	the --host/target/build tupples
	the compiler
	the path to the source tree
	the build date
	the user/machine

Assuming your suggestion works (JimK doesn't find more technical flaws
(1) :-) A change putting tm/xm/hm into config.h is ok with me :-)

	Andrew

(1) I think changing tm/xm/nm happens sufficiently often for it to be
dangerous to not force a rebuild.
From ac131313@cygnus.com Sun Mar 05 01:03:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility
Date: Sun, 05 Mar 2000 01:03:00 -0000
Message-id: <38C22262.FFA0191@cygnus.com>
References: <38BC81A0.17D25C8@cygnus.com> <bbt4y3s8k.fsf@rtl.cygnus.com> <38BE146B.46ED6E4D@cygnus.com> <200003021446.JAA31093@devserv.devel.redhat.com>
X-SW-Source: 2000-03/msg00081.html
Content-length: 1917

Jim Kingdon wrote:
> 
> > Sorry, devolve, as a word, is probably more meaningful to people from
> > Commonwealth countries.
> 
> I'm familiar with the word (e.g. Scotland) but at least for me it has
> all these connotations of national sovereignty and power and such.
> For example, it is a dead end to assume that an OS vendor should
> automatically maintain GDB on that OS because they "own" the platform
> or something.
> 
> > The underlying concern I have isn't with people like you that have been
> > hacking on open code for years, its with people familar with GDB but not
> > so familar with open source.  For that reason, I think it is useful to
> > spell out, in basic terms, how the system should work.
> 
> Maybe link to The Cathedral and the Bazaar (which is well known) and
> Alan Cox's Town Council paper (which deserves to be better known and
> is at http://slashdot.org/features/98/10/13/1423253.shtml )?  I was
> just showing the Town Council paper to someone in a GDB context and it
> seemed to resonate.
> 
> I'm sure the looseness of this approach will make some people nervous.
> But you can't build trust through rules and policies either.  What is
> going to turn GDB development into the (more) vibrant community we
> want it to be is delivering on the promises to add maintainers and
> otherwise open up.  We've made great progress in the last month and
> let's keep it up.

Try this:

``
Note individuals who maintain parts of the debugger need approval to
check in changes outside of the immediate domain that they maintain.

If there is no maintainer for a given domain then the responsibility
falls to the head maintainer.

If there are several maintainers for a given domain then
responsibility falls to the first maintainer.  The first maintainer is
free to devolve maintainership responsibility anyway they like.

Refs: http://slashdot.org/features/98/10/13/1423253.shtml

''

	Andrew
From johan.rydberg@netinsight.se Sun Mar 05 07:57:00 2000
From: Johan Rydberg <johan.rydberg@netinsight.se>
To: gdb@sourceware.cygnus.com
Subject: probelms with registers
Date: Sun, 05 Mar 2000 07:57:00 -0000
Message-id: <38C292EF.50B53C09@netinsight.se>
X-SW-Source: 2000-03/msg00082.html
Content-length: 682

Hi!

I'm developing a "gdb-simulator" for a CPU, and it seems to
work pretty good. But I have some questions. When I try to
display the registers it says everyone except the link register
is unavailable. Why this?  It also fetches the PC register, but
it also says it's unavailable.

And, how do I from gdb call the `sim_info´ function?  Right 
now I have implemented a "sim info" command, but since it's 
defined in the simulator interface I guess that there's a 
better way to do this.

regards,
Johan.

-- 
Johan Rydberg			johan.rydberg@netinsight.net
Net Insight AB, Sweden		direct: +46-8-685 04 17
http://www.netinsight.net	phone:  +46-8-685 04 00
				fax:    +46-8-685 04 20
From kingdon@redhat.com Sun Mar 05 10:10:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility
Date: Sun, 05 Mar 2000 10:10:00 -0000
Message-id: <200003051810.NAA09213@devserv.devel.redhat.com>
References: <38BC81A0.17D25C8@cygnus.com> <bbt4y3s8k.fsf@rtl.cygnus.com> <38BE146B.46ED6E4D@cygnus.com> <200003021446.JAA31093@devserv.devel.redhat.com> <38C22262.FFA0191@cygnus.com>
X-SW-Source: 2000-03/msg00083.html
Content-length: 36

> Try this:

That looks fine to me.
From schwab@suse.de Mon Mar 06 02:55:00 2000
From: Andreas Schwab <schwab@suse.de>
To: leisner@rochester.rr.com
Cc: shebs@apple.com, gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Should GCC tell GDB about its optimizations?
Date: Mon, 06 Mar 2000 02:55:00 -0000
Message-id: <200003061054.LAA20310@hawking.suse.de>
References: <200003040446.XAA04330@rochester.rr.com>
X-SW-Source: 2000-03/msg00084.html
Content-length: 1609

"Marty Leisner" <leisner@rochester.rr.com> writes:

|> Yes...!!!
|> 
|> I proposed something like this years ago...I almost hacked up
|> gcc to put this in (I think I started...)
|> 
|> It is incredibly useful in the real world to encapsulate what
|> compiler flags were used in the binary (essentially the gcc command
|> line with preprocessor flags).
|> 
|> I just compiled a trivial C program with -O3 to see..
|> 
|> The .s file has
|>   .ident  "GCC: (GNU) 2.95.2 19991024 (release)"
|> 
|> Is there a way for nm to decode this?  (strings can show it, 
|> but its pretty meaningless in the binary).
|> 
|> For example:
|> ...
|> GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
|> GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
|> GCC: (GNU) 2.95.2 19991024 (release)
|> GCC: (GNU) 2.95.2 19991024 (release)
|> GCC: (GNU) 2.95.2 19991024 (release)
|> GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
|> ....
|> 
|> I don't know how to take apart elf binaries off the top
|> of my head, but I assume there is information someplace encoded
|> to match this up with specific files.

This information is concatenated in the .comment section.  It can be
listed with "objdump -sj.comment ....".  But there is no easy way to map
it back to the object modules apart from the fact that the order is the
same as the order of the modules linked in.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
From ezannoni@cygnus.com Mon Mar 06 09:56:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb@sourceware.cygnus.com, ezannoni@cygnus.com
Subject: Re: Buffering problems with "gdb < foo"
Date: Mon, 06 Mar 2000 09:56:00 -0000
Message-id: <14531.61750.823726.628635@kwikemart.cygnus.com>
References: <200003050850.DAA10185@indy.delorie.com>
X-SW-Source: 2000-03/msg00085.html
Content-length: 1497

Eli Zaretskii writes:
 > 
 > A comment in event-top.c (inside the change_line_handler function)
 > says this:
 > 
 >   /* NOTE: this operates on input_fd, not instream. If we are reading
 >      commands from a file, instream will point to the file. However in
 >      async mode, we always read commands from a file with editing
 >      off. This means that the 'set editing on/off' will have effect
 >      only on the interactive session. */
 > 
 > However, running "gdb < foo" seems to contradict this: I put a
 > breakpoint in gdb_readline2, and it is never hit.  Am I missing
 > something?
 > 

Yeah, I tried to think hard about all the possible cases, but
obvioulsy I missed this one. 

 > The problem with this is that if the file `foo' includes a command
 > which needs a confirmation, the call to fgetc in query will eatup lots
 > of characters which will never again be seen by the event loop.  In my
 > case, fgetc read all the file (it was small), so GDB hit EOF and
 > exited.  I can prevent this from happening by putting "set editing off"
 > in the input file.  Invoking GDB with --noasync also solves the
 > problem.
 > 

Yep.

 > Does this work on Unix?  If so, it would make this a DJGPP-specific
 > problem.

I haven't tried, but probably it won't. Can you send me your command file?

 > 
 > If this is not DJGPP-specific, then I think _initialize_event_loop
 > should turn editing off if input_fd is not a tty.

I think so, can you submit a patch to do this? 

Thanks.

Elena
From tennis@cisco.com Mon Mar 06 10:37:00 2000
From: Tennis Smith <tennis@cisco.com>
To: gdb-trolls@cisco.com, gdb@sourceware.cygnus.com
Subject: Finding a Source File
Date: Mon, 06 Mar 2000 10:37:00 -0000
Message-id: <4.1.20000306101424.00a5a510@lethe>
X-SW-Source: 2000-03/msg00086.html
Content-length: 972

Hi,

I'm trying to set a breakpoint in a file that is indirectly
included in my project.  When I try to set a breakpoint
on it, the following message occurs:

No source file named MismatchedTokenException.cpp.

The file lives in a separate tree which contains various support
routines.  I've added to my path the location of the file, but
that didn't work.  

Any ideas??

TIA,
-Tennis 
 
-------------------------------------------------------------------------
     |          |      Cisco Systems, Inc.     Tennis Smith
    |||        |||     170 West Tasman Drive   Software Engineer
   |||||      |||||    San Jose, CA 95134-1706 Test Technology
.:|||||||:..:|||||||:. Phone: (408) 527-4424
                       Fax:   (408) 527-6245  tennis@cisco.com
  Cisco Systems Inc.                           Pager: 1-800-796-7363
                       "Yes, it's my real name..."     PIN# 101-0528
-------------------------------------------------------------------------