Re: Should GCC tell GDB about its optimizations?

["Timothy J. Wood" <tjw@omnigroup.com>]

From: Stan Shebs <shebs@apple.com>
>But today, the result is just lame; hackers
t>rying to debug get lots of squirrelly behavior from GDB.


  What sort of squirrelly behavior are you talking about exactly?  If it is 
just the typical problem where GCC reuses register's and stack locations 
when variables lifetime's are over, this would seem like a gdb problem, not 
a GCC problem.  gdb should be able to look at the debugging info and notice 
that the variable you are trying to print is not currently live.  It could 
then print out a message that says so, rather than printing out whatever 
random crud happens to be at the place of the variable's death.

  Of course, I only know about the stabs format (and only as used on MacOS X 
Server/MacOS X) -- this format seems to provide enough information to 
implement this behavior in gdb.  I would assume that other debug info 
formats would have the same information.

  Is there some other behavior that isn't covered by the above?

-tim
From brg@sartre.dgate.ORG Fri Mar 03 17:38:00 2000
From: "Brian R. Gaeke" <brg@sartre.dgate.ORG>
To: Stan Shebs <shebs@apple.com>
Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Should GCC tell GDB about its optimizations?
Date: Fri, 03 Mar 2000 17:38:00 -0000
Message-id: <20000303173847.A1487@celes.dgate.ORG>
References: <38C051C3.260D666B@apple.com>
X-SW-Source: 2000-03/msg00067.html
Content-length: 1596

And then spake Stan Shebs, as follows:
> Ideally of course, GCC would issue lots of amazingly detailed debug info,
> and GDB would use it to reconstruct and report program state just as the
> programmer expects to see it.  But today, the result is just lame; hackers
> trying to debug get lots of squirrelly behavior from GDB.  The problem is
> that they don't know whether the randomness is due to bugs in the program,
> or to the effect of the optimizer.  So the suggestion came up to have GCC
> issue debug info stating what optimizations have been applied to a file,
> and to have GDB report that information per-function, so that users could
> lower their expectations appropriately.

You may (or perhaps may not) find some of the material Caroline Tice has
worked on here at UCB useful -- ISTR she was investigating debugging
optimized code and did work on a compiler that outputted a lot of
information on the transformations that were applied to the code (and
debugging tools that used it.)

Disclaimer: I don't have any direct knowledge of how her code did what
it did, so I can't really be of much help -- but I just thought that
her dissertation talk sounded a lot like what you are trying to do...

http://sunsite.berkeley.edu/Dienst/UI/2.0/Describe/ncstrl.ucb/CSD-99-1077
http://www.cs.berkeley.edu/~cmtice/

-Brian

-- 
Brian R. Gaeke, brg@sartre.dgate.ORG -- PGP/GPG gleefully accepted
"the iguana / in the petshop window on St Catherine Street / crested,
 royal-eyed, ruling / its kingdom of water-dish and sawdust / dreams of
 sawdust" - Margaret Atwood, "Dreams of the Animals"
From leisner@rochester.rr.com Fri Mar 03 22:08:00 2000
From: "Marty Leisner" <leisner@rochester.rr.com>
To: shebs@apple.com
Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com, leisner@rochester.rr.com
Subject: Re: Should GCC tell GDB about its optimizations? 
Date: Fri, 03 Mar 2000 22:08:00 -0000
Message-id: <200003040446.XAA04330@rochester.rr.com>
References: <38C051C3.260D666B@apple.com>
X-SW-Source: 2000-03/msg00068.html
Content-length: 3255

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.

gdb doesn't have to warn, but you should be able to use a tool
to figure this out.

Marty Leisner


Stan Shebs <shebs@apple.com> writes  on Fri, 03 Mar 2000 15:58:59 PST
     > 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.
     > 
     > Ideally of course, GCC would issue lots of amazingly detailed debug 
info,
     > and GDB would use it to reconstruct and report program state just as the
     > programmer expects to see it.  But today, the result is just lame; 
hackers
     > trying to debug get lots of squirrelly behavior from GDB.  The problem 
is
     > that they don't know whether the randomness is due to bugs in the 
program,
     > or to the effect of the optimizer.  So the suggestion came up to have 
GCC
     > issue debug info stating what optimizations have been applied to a file,
     > and to have GDB report that information per-function, so that users 
could
     > lower their expectations appropriately.
     > 
     > Although my first reaction was to say "bleah", upon reflection I 
wondered
     > if I was too easily dismissing the concerns of real users of the tools.
     > This sort of thing routinely confuses users; even with years of GNU
     > experience, I still find myself being caught by surprise because I've
     > forgotten that part of the code was optimized.  A simple warning from 
the
     > debugger would have saved me some time and trouble.
     
     > If there's consensus that this would be a worthwhile addition, I'll
     > work up a specific design and publish it.
     > 
     > Stan