From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephane Carrez To: shebs@apple.com Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com Subject: Re: Should GCC tell GDB about its optimizations? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: <38C0ED65.94E305D9@worldnet.fr> References: <38C051C3.260D666B@apple.com> X-SW-Source: 2000-q1/msg00540.html Message-ID: <20000401000000.G282w8BZpqHJeq_qU4HUJTaq47Oe9jZlawk3bpjENM8@z> 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" 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 jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: memory region attribute CLI Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00703.html Content-length: 1326 I've been told to work on memory region attributes full time, so I expect to make significant progress in the next few days. * create memory region: mem attribute [attribute ...] example: (gdb) mem 0x00008000 0x0000FFFF ro 8 (gdb) mem 0x00007FF0 0x00007FFF rw (gdb) mem 0x00007FE0 0x00007FEF wo 16 (gdb) mem 0x00007FD0 0x00007FDF ro I've followed the behavior of "display" and do not output a message indicating the number of the memory region that has been created. But as I write this message, it seems that it probably should. I think an argument could be made that the same should be done for displays... * enable/disable memory region: enable mem [ ...] disable mem [ ...] example: (gdb) disable mem 2 * delete memory regions: delete mem [ ...] example: (gdb) delete mem 3 * show memory regions: info mem example: (gdb) info mem Num Enb Address Attr 1: y 0x00008000-0x0000FFFF ro, 8 2: n 0x00007FF0-0x00007FFF rw 4: y 0x00007FD0-0x00007FDF ro Thoughts? --jtc -- J.T. Conklin RedBack Networks >From dje@transmeta.com Sat Apr 01 00:00:00 2000 From: Doug Evans To: gdb@sourceware.cygnus.com Cc: dje@transmeta.com Subject: Guile scripting Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002132323.PAA12301@casey.transmeta.com> X-SW-Source: 2000-q1/msg00256.html Content-length: 997 I found this in the gdb archives. What's the state of "first version of libgdb, w/Guile scripting" ? --- To: gdb at sourceware dot cygnus dot com Subject: Re: Next release of GDB From: James Ingham Date: 07 Sep 1999 09:32:06 -0700 Newsgroups: cygnus.gdb Organization: Cygnus Solutions References: <199909051618.SAA01412@caracol.first.gmd.de> Clemens Klein-Robbenhaar writes: Presumably, the Objective C support would be in the MacOS X Support bits. MacOS X being based on NextStep, which is in turn heavily Objective C based... Jim > Stan Shebs wrote: > > [...] > > Here are some additional things that I would like to see, but that > > ought not to hold up the release if they can't be gotten in: > > > > * first version of libgdb, w/Guile scripting > > * GNU/Linux thread_db library support > > * asynchronous execution for GNU/Linux > > * fork following for GNU/Linux > > * HP WDB 1.1 bits >From ogoh@cise.ufl.edu Sat Apr 01 00:00:00 2000 From: "Okehee Goh" To: Subject: Error during installing GDB using Cygwin32. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <001501bf5b23$b053fb20$8daae380@hsilab.cise.ufl.edu> X-SW-Source: 2000-q1/msg00015.html Content-length: 720 Hi, I'm now trying to install gdb-4.18 on the win98 using cygwin32. But it gave out the following error message and faild to make gdb.exe. "gdb-4.18/readline/kill.c:611: undefined reference to 'OpenClipboard' gdb-4.18/readline/kill.c:611: undefined reference to 'GetClipboardData' gdb-4.18/readline/kill.c:611: undefined reference to 'CloseClipboard'" When I examined the related part of above error at kill.c, these function was to support Cygwin32. How can I deal with this problem? Is there any patch for solving this problem? Thanks in advance. ******************************************************************** Okehee Goh RealTime System Lab. (T) 1-352-392-6836 CISE Dept. University Of Florida