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, 04 Mar 2000 03:03:00 -0000 Message-id: <38C0ED65.94E305D9@worldnet.fr> References: <38C051C3.260D666B@apple.com> X-SW-Source: 2000-03/msg00075.html 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 eliz@delorie.com Sat Mar 04 23:38:00 2000 From: Eli Zaretskii 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> <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 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 > > * 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 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 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 To: Eli Zaretskii 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> <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 To: Jim Kingdon 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> <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 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 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> <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 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" 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 To: Eli Zaretskii 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 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 ------------------------------------------------------------------------- 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