From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Timothy J. Wood" To: shebs@apple.com Cc: gdb@sourceware.cygnus.com, gcc@gcc.gnu.org Subject: Re: Should GCC tell GDB about its optimizations? Date: Fri, 03 Mar 2000 17:03:00 -0000 Message-id: <0003031702.AA550283@electabuzz> References: <38C051C3.260D666B@apple.com> X-SW-Source: 2000-03/msg00066.html From: Stan Shebs >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" To: Stan Shebs 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" 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 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