From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE Cc: kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Thu, 02 Mar 2000 08:56:00 -0000 Message-id: <20000302090343I.mitchell@codesourcery.com> References: <20000302023420H.mitchell@codesourcery.com> <200003021143.MAA14294@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-03/msg00046.html >>>>> "Peter" == Peter Schauer writes: Peter> with GCC or GDB), a breakpoint on the opening brace is not Peter> what I want, as I will almost always have to step over it. Peter> I'd expect a breakpoint on the first local variable that Peter> needs initalization, or the first statement. Yes, I think we're all agreed. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com >From mark@codesourcery.com Thu Mar 02 08:59:00 2000 From: Mark Mitchell To: kettenis@wins.uva.nl Cc: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Thu, 02 Mar 2000 08:59:00 -0000 Message-id: <20000302090701N.mitchell@codesourcery.com> References: <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de> <20000302023420H.mitchell@codesourcery.com> <200003021246.e22CkWL00549@delius.kettenis.local> X-SW-Source: 2000-03/msg00047.html Content-length: 937 >>>>> "Mark" == Mark Kettenis writes: Mark> some bit rot since then. Are the prologue's generated by Mark> GCC any different from those generated back in 1994? I dunno, but my guess is that's not the bug. Right now, the problem is: o We put line notes in the prologue o We weren't putting line notes before the first real code, so GCC was skipping over that too. o I promoted the last line note in the prologue to appear before the first real code, bringing GCC back to seme-sensible behavior. We could try to: o Not emit line notes in the prologue that correspond to the '{' line. o Try to find the first line note in the real code, instead of the last line note in the prologue. The latter is probably easiest, but is still harder that what I did. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com >From gzp@gzp.org.hu Thu Mar 02 11:48:00 2000 From: "Gabor Z. Papp" To: gdb@sourceware.cygnus.com Subject: gdb cvs Date: Thu, 02 Mar 2000 11:48:00 -0000 Message-id: <20000302204824.B18856@gzp.org.hu> References: <200003021924.e22JO4U19747@mail.gzp.org.hu> X-SW-Source: 2000-03/msg00048.html Content-length: 5091 | cvs server: Updating gdb | U gdb/CONTRIBUTE [...] | U gdb/vx-share/xdr_rdb.h | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/texinfo | cvs server: ignoring module src/texinfo | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/bfd | cvs server: ignoring module src/bfd | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/opcodes | cvs server: ignoring module src/opcodes | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/readline | cvs server: ignoring module src/readline | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/libiberty | cvs server: ignoring module src/libiberty | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/mmalloc | cvs server: ignoring module src/mmalloc | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/include | cvs server: ignoring module src/include | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/sim | cvs server: ignoring module src/sim | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/utils | cvs server: ignoring module src/utils | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/.cvsignore | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/COPYING | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/COPYING.LIB | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/ChangeLog | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/Makefile.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/README | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/config | cvs server: ignoring module src/config | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/config-ml.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/config.guess | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/config.if | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/config.sub | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/configure | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/configure.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/etc | cvs server: ignoring module src/etc | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/install-sh | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/ltconfig | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/ltmain.sh | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/makefile.vms | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/missing | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mkdep | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mkinstalldirs | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/move-if-change | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-README | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-build.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-config.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-configure | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-install | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/setup.com | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/symlink-tree | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/ylwrap | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/intl | cvs server: ignoring module src/intl Is this correct? >From ac131313@cygnus.com Thu Mar 02 16:22:00 2000 From: Andrew Cagney To: "Gabor Z. Papp" Cc: gdb@sourceware.cygnus.com Subject: Re: gdb cvs Date: Thu, 02 Mar 2000 16:22:00 -0000 Message-id: <38BF0551.9B4FE1E@cygnus.com> References: <200003021924.e22JO4U19747@mail.gzp.org.hu> <20000302204824.B18856@gzp.org.hu> X-SW-Source: 2000-03/msg00049.html Content-length: 299 "Gabor Z. Papp" wrote: > > | cvs server: Updating gdb > | U gdb/CONTRIBUTE > > [...] > > > Is this correct? Were you doing a: ``co gdb'' over the top of an existing tree? I've encountered that message then. I suspect it isn't correct but, from what I saw it still did what I wanted. Andrew >From muller@cerbere.u-strasbg.fr Fri Mar 03 00:28:00 2000 From: Pierre Muller To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: RFD: New command to inspect other selectors memory. Date: Fri, 03 Mar 2000 00:28:00 -0000 Message-id: <200003030843.JAA12246@cerbere.u-strasbg.fr> References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00050.html Content-length: 1161 I inserted this in a reply about pascal extension, but as I got no answer, I thought I will send it as a separate message. I have written for DJGPP target a relatively small patch. It allows to read memory from another selector this was very useful for me when I tried to debug the debugger itself and when I added exception support fro GDB on DJGPP ! This patch consists of the addition of one command that I called "xx" which is a simple clone of the "x" command but can take a selector as for intance "xx $fs:0x400" then the next "xx 0x800" keeps using the last selector value. I do not know if this could be interesting for other i386 targets (maybe for win32 to be able to see the content of the $fs selector that contains the exception chain, but I am not sure how if its readable inside a win32 API program). Is such kind of patch too specific to have any chance to get accepted ? I don't know if it could be of any use for other processors or operating system !! Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 >From ac131313@cygnus.com Fri Mar 03 00:56:00 2000 From: Andrew Cagney To: tromey@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: 5.0 known issues 2000-02-16 Date: Fri, 03 Mar 2000 00:56:00 -0000 Message-id: <38BF7E1D.4E0A904D@cygnus.com> References: <38AA42EA.5106E153@cygnus.com> <87ael1ynl8.fsf@cygnus.com> X-SW-Source: 2000-03/msg00051.html Content-length: 354 Tom Tromey wrote: > > >>>>> "Andrew" == Andrew Cagney writes: > > Andrew> GNU/Linux/i386: > > Without my patch, gdb doesn't work at all when run on x86 Linux boxes > with older kernels (I still run 2.0.34). Tom, I belive JimB's bubbled this up to the top of his queue and made it one of the things try to get into 5.0 Andrew >From ac131313@cygnus.com Fri Mar 03 01:16:00 2000 From: Andrew Cagney To: Jimmy Guo Cc: GDB Discussion Subject: Re: 5.0 known issues 2000-02-16 Date: Fri, 03 Mar 2000 01:16:00 -0000 Message-id: <38BF81BD.C7C35B59@cygnus.com> References: X-SW-Source: 2000-03/msg00052.html Content-length: 699 Jimmy Guo wrote: > > >HP/UX: Unfortunately this was knocked about pretty badly by the move to > >an external repository (sorry). Jimmy's looking at it along with Jason > >and (possibly) Jeff (shared lib problem). I'm also going to try get > >access to a HPUX box and give it a whirl. > > Provided that Jeff has applied the changes (include/hp-symtab.h) into > the public repository, GDB should build for HP targets. > > Currently we're still relying on weekly snapshots to pick up updates. I > know this would have to change for us to access CVS directly ... once > there's a snapshot I will see if it is fixed ... Just FYI, Hopefully the weekly snapshots are starting to flow again. Andrew >From insulaner_andi@yahoo.com Fri Mar 03 02:18:00 2000 From: Andreas Kuepper To: gdb@sourceware.cygnus.com Subject: running GDB on Cygwin Date: Fri, 03 Mar 2000 02:18:00 -0000 Message-id: <20000303101528.22003.qmail@web3402.mail.yahoo.com> X-SW-Source: 2000-03/msg00053.html Content-length: 364 Is there anybody who ever tried to run GDB on Cygwin? I want to do remote debugging and when I run "configure" it fails with the message : configure: error: could not find term library Thanks for your help! Andreas Kuepper __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com >From kettenis@wins.uva.nl Fri Mar 03 04:40:00 2000 From: Mark Kettenis To: muller@cerbere.u-strasbg.fr Cc: gdb@sourceware.cygnus.com Subject: Re: RFD: New command to inspect other selectors memory. Date: Fri, 03 Mar 2000 04:40:00 -0000 Message-id: <200003031240.e23CeRn00162@delius.kettenis.local> References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00054.html Content-length: 1571 Date: Fri, 03 Mar 2000 09:27:14 +0100 From: Pierre Muller I inserted this in a reply about pascal extension, but as I got no answer, I thought I will send it as a separate message. Sorry about that. I have written for DJGPP target a relatively small patch. It allows to read memory from another selector this was very useful for me when I tried to debug the debugger itself and when I added exception support fro GDB on DJGPP ! This patch consists of the addition of one command that I called "xx" which is a simple clone of the "x" command but can take a selector as for intance "xx $fs:0x400" then the next "xx 0x800" keeps using the last selector value. I do not know if this could be interesting for other i386 targets (maybe for win32 to be able to see the content of the $fs selector that contains the exception chain, but I am not sure how if its readable inside a win32 API program). Is such kind of patch too specific to have any chance to get accepted ? I don't know if it could be of any use for other processors or operating system !! This may be impossible to implement on most i386 targets (with the possible exception of Solaris and Mach-based targets), but nevrtheless it could be useful to have for things that are a bit more low-level (like debugging a threads library that uses segmentation to store per-thread data and such). The suggested syntax could probably be improved, since "xx" isn't very descriptive. People with bright ideas? Mark >From ac131313@cygnus.com Fri Mar 03 04:52:00 2000 From: Andrew Cagney To: Pierre Muller Cc: Mark Kettenis , gdb@sourceware.cygnus.com Subject: Re: RFD: New command to inspect other selectors memory. Date: Fri, 03 Mar 2000 04:52:00 -0000 Message-id: <38BFB50A.606036CF@cygnus.com> References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00055.html Content-length: 1420 Pierre Muller wrote: > > I inserted this in a reply about pascal extension, but as I got no answer, > I thought > I will send it as a separate message. > > I have written for DJGPP target a relatively small patch. > It allows to read memory from another selector > this was very useful for me when I tried to debug the debugger itself and > when I added exception support fro GDB on DJGPP ! > > This patch consists of the addition of one command that I called "xx" > which is a simple clone of the "x" command but can take a selector > as for intance > "xx $fs:0x400" > then the next "xx 0x800" keeps using the last selector value. > I do not know if this could be interesting for other i386 targets > (maybe for win32 to be able to see the content of the $fs selector > that contains the exception chain, but I am not sure how if its > readable inside a win32 API program). > > Is such kind of patch too specific to have any chance to get accepted ? > I don't know if it could be of any use for other processors or operating > system !! I'm not sure what the x86 people will do. However the generic problem of getting GDB to understand segments is one of those things that has long sat on peoples wishlists. The theory is that if ``CORE_ADDR'' is made in to a pretend object (ISO-C remember :-) and then the rest falls out.... As they say, the proof is left as an exercise to the reader. enjoy, Andrew >From muller@cerbere.u-strasbg.fr Fri Mar 03 06:47:00 2000 From: Pierre Muller To: gdb@sourceware.cygnus.com Subject: 2 pascal language patches inserted in database Date: Fri, 03 Mar 2000 06:47:00 -0000 Message-id: <200003031500.QAA18276@cerbere.u-strasbg.fr> References: <200003021452.PAA02334@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00056.html Content-length: 423 I submitted two patches for pascal extension in the database! I am subscribed to gdb-patches and I think that this should be enough to gt also all mails generated by the gdb patch database, but I saw a subcribe link! Why is this distinct ? Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 >From hjl@lucon.org Fri Mar 03 07:17:00 2000 From: "H . J . Lu" To: Andrew Cagney Cc: tromey@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: 5.0 known issues 2000-02-16 Date: Fri, 03 Mar 2000 07:17:00 -0000 Message-id: <20000303071729.B31569@lucon.org> References: <38AA42EA.5106E153@cygnus.com> <87ael1ynl8.fsf@cygnus.com> <38BF7E1D.4E0A904D@cygnus.com> X-SW-Source: 2000-03/msg00057.html Content-length: 705 On Fri, Mar 03, 2000 at 07:55:57PM +1100, Andrew Cagney wrote: > Tom Tromey wrote: > > > > >>>>> "Andrew" == Andrew Cagney writes: > > > > Andrew> GNU/Linux/i386: > > > > Without my patch, gdb doesn't work at all when run on x86 Linux boxes > > with older kernels (I still run 2.0.34). > > Tom, > > I belive JimB's bubbled this up to the top of his queue and made it one > of the things try to get into 5.0 FWIW, the static gdb binary of gdb 4.17.0.1x compiled with glibc 2.1 and kernel 2.2 works on kernel >= 2.0, libc 5, glibc 2.0 and glibc 2.1. It should also work on glibc 2.2. Kernel and libc are detected at the runtime. It will be nice that 5.0 can do the same. H.J. >From kettenis@wins.uva.nl Fri Mar 03 07:31:00 2000 From: Mark Kettenis To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: `long double' support for ix86 targets Date: Fri, 03 Mar 2000 07:31:00 -0000 Message-id: <200003031531.e23FV8T00285@delius.kettenis.local> X-SW-Source: 2000-03/msg00058.html Content-length: 5450 Hi, Kevin's changes to findvar.c:extract_floating() and store_floating() together with some further analysis have convinced me that for all but one ix86 targets 96-bit long doubles of type &floatformat_i387_ext are the right thing. This would give most of the ix86 targets instant support for long doubles. It also gives us the opportunity to remove some ugly bits introduced by people who tried to hack around the current limitations. Here are some personal notes I made about this: Support for `long double' ------------------------- The majority of i386 targets in GCC have a `long double' that is 96 bits wide (of which only 80 bits are used, the rest is padding). In fact the only exception is OSF/1, where `long double' is equivalent to `double' and has only 64 bits. This length of 96 bits is also used in the debugging information generated by the compiler. The origional i386 System V ABI specification doesn't say anything about `long double', but the new (draft) IA-64 System V ABI specification uses a `long double' of 96 bits for things running in 32-bit mode. I guess that 32-bit mode is supposed to be provided for compatible with IA-32, this implies that 96 bits is supposed to be the standard. Therefore, `config/i386/tm-i386.h' should define: #define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext #define TARGET_LONG_DOUBLE_BITS 96 Targets such as OSF/1 can override this. If we do the above, we can make the default "virtual" type of the FPU registers `builtin_type_long_double'. A lot of the Linux cruft for dealing with `long double' could be removed. 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. Index: config/i386/tm-i386.h =================================================================== RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v retrieving revision 1.2 diff -u -p -r1.2 tm-i386.h --- config/i386/tm-i386.h 2000/02/29 13:28:24 1.2 +++ config/i386/tm-i386.h 2000/03/03 15:00:49 @@ -1,5 +1,5 @@ /* Macro definitions for GDB on an Intel i[345]86. - Copyright (C) 1995, 1996 Free Software Foundation, Inc. + Copyright (C) 1995, 1996, 2000 Free Software Foundation, Inc. This file is part of GDB. @@ -28,6 +28,19 @@ struct type; #define TARGET_BYTE_ORDER LITTLE_ENDIAN +/* The format used for `long double' on almost all i386 targets is the + i387 extended floating-point format. In fact, of all targets in the + GCC 2.95 tree, only OSF/1 does it different, and insists on having + a `long double' that's not `long' at all. */ + +#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext + +/* Although the i386 extended floating-point has only 80 significant + bits, a `long double' actually takes up 96, probably to enforce + alignment. */ + +#define TARGET_LONG_DOUBLE_BITS 96 + /* Used for example in valprint.c:print_floating() to enable checking for NaN's */ @@ -229,7 +242,7 @@ extern int i386_register_virtual_size[]; #define REGISTER_VIRTUAL_TYPE(N) \ (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM) \ ? lookup_pointer_type (builtin_type_void) \ - : IS_FP_REGNUM(N) ? builtin_type_double \ + : IS_FP_REGNUM(N) ? builtin_type_long_double \ : IS_SSE_REGNUM(N) ? builtin_type_v4sf \ : builtin_type_int) @@ -239,25 +252,22 @@ extern int i386_register_virtual_size[]; that SSE registers need conversion. Even if we can't find a counterexample, this is still sloppy. */ #define REGISTER_CONVERTIBLE(n) (IS_FP_REGNUM (n)) - -/* Convert data from raw format for register REGNUM in buffer FROM - to virtual format with type TYPE in buffer TO. */ -extern void i387_to_double (char *, char *); +/* Convert data from raw format for register REGNUM in buffer FROM to + virtual format with type TYPE in buffer TO. In principle both + formats are identical except that the virtual format has two extra + bytes appended that aren't used. We set these to zero. */ #define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO) \ -{ \ - double val; \ - i387_to_double ((FROM), (char *)&val); \ - store_floating ((TO), TYPE_LENGTH (TYPE), val); \ -} - -extern void double_to_i387 (char *, char *); - -#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \ -{ \ - double val = extract_floating ((FROM), TYPE_LENGTH (TYPE)); \ - double_to_i387((char *)&val, (TO)); \ -} + { \ + memset ((TO), 0, TYPE_LENGTH (TYPE)); \ + memcpy ((TO), (FROM), FPU_REG_RAW_SIZE); \ + } + +/* Convert data from virtual format with type TYPE in buffer FROM to + raw format for register REGNUM in buffer TO. Simply omit the two + unused bytes. */ +#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \ + memcpy ((TO), (FROM), FPU_REG_RAW_SIZE) /* Print out the i387 floating point state. */ #ifdef HAVE_I387_REGS >From ezannoni@cygnus.com Fri Mar 03 07:52:00 2000 From: Elena Zannoni To: gdb@sourceware.cygnus.com Subject: PATCH: Eliminate some uses of PTR. Date: Fri, 03 Mar 2000 07:52:00 -0000 Message-id: <14527.57252.598442.150750@kwikemart.cygnus.com> X-SW-Source: 2000-03/msg00059.html Content-length: 4376 This eliminates uses of PTR from event-loop.h, event-top.c. I've checked this in. Elena Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.96 diff -c -r1.96 ChangeLog *** ChangeLog 2000/03/03 02:18:26 1.96 --- ChangeLog 2000/03/03 15:26:44 *************** *** 1,3 **** --- 1,12 ---- + 2000-03-03 Elena Zannoni + + * defs.h (struct continuation_arg): Change type of field 'data' + from PTR to void *. + + * event-loop.h: Eliminate uses of PTR, use 'void *' instead. + + * event-top.c: Ditto. + 2000-03-02 Elena Zannoni * config/alpha/alpha-linux.mh: Remove core-regset.o fron the Index: defs.h =================================================================== RCS file: /cvs/src/src/gdb/defs.h,v retrieving revision 1.4 diff -c -r1.4 defs.h *** defs.h 2000/02/24 00:04:03 1.4 --- defs.h 2000/03/03 15:26:44 *************** *** 613,619 **** struct continuation_arg { struct continuation_arg *next; ! PTR data; }; struct continuation --- 613,619 ---- struct continuation_arg { struct continuation_arg *next; ! void *data; }; struct continuation Index: event-loop.h =================================================================== RCS file: /cvs/src/src/gdb/event-loop.h,v retrieving revision 1.1.1.15 diff -c -r1.1.1.15 event-loop.h *** event-loop.h 1999/10/05 23:08:11 1.1.1.15 --- event-loop.h 2000/03/03 15:26:44 *************** *** 57,63 **** Corollary tasks are the creation and deletion of event sources. */ ! typedef PTR gdb_client_data; struct async_signal_handler; typedef void (handler_func) (int, gdb_client_data); typedef void (sig_handler_func) (gdb_client_data); --- 57,63 ---- Corollary tasks are the creation and deletion of event sources. */ ! typedef void * gdb_client_data; struct async_signal_handler; typedef void (handler_func) (int, gdb_client_data); typedef void (sig_handler_func) (gdb_client_data); Index: event-top.c =================================================================== RCS file: /cvs/src/src/gdb/event-top.c,v retrieving revision 1.2 diff -c -r1.2 event-top.c *** event-top.c 2000/02/23 00:25:42 1.2 --- event-top.c 2000/03/03 15:26:44 *************** *** 129,145 **** handlers mark these functions as ready to be executed and the event loop, in a later iteration, calls them. See the function invoke_async_signal_handler. */ ! PTR sigint_token; #ifdef SIGHUP ! PTR sighup_token; #endif ! PTR sigquit_token; ! PTR sigfpe_token; #if defined(SIGWINCH) && defined(SIGWINCH_HANDLER) ! PTR sigwinch_token; #endif #ifdef STOP_SIGNAL ! PTR sigtstp_token; #endif /* Structure to save a partially entered command. This is used when --- 129,145 ---- handlers mark these functions as ready to be executed and the event loop, in a later iteration, calls them. See the function invoke_async_signal_handler. */ ! void *sigint_token; #ifdef SIGHUP ! void *sighup_token; #endif ! void *sigquit_token; ! void *sigfpe_token; #if defined(SIGWINCH) && defined(SIGWINCH_HANDLER) ! void *sigwinch_token; #endif #ifdef STOP_SIGNAL ! void *sigtstp_token; #endif /* Structure to save a partially entered command. This is used when *************** *** 525,532 **** (struct continuation_arg *) xmalloc (sizeof (struct continuation_arg)); arg1->next = arg2; arg2->next = NULL; ! arg1->data = (PTR) time_at_cmd_start; ! arg2->data = (PTR) space_at_cmd_start; add_continuation (command_line_handler_continuation, arg1); } --- 525,532 ---- (struct continuation_arg *) xmalloc (sizeof (struct continuation_arg)); arg1->next = arg2; arg2->next = NULL; ! arg1->data = (void *) time_at_cmd_start; ! arg2->data = (void *) space_at_cmd_start; add_continuation (command_line_handler_continuation, arg1); } *************** *** 957,963 **** } void ! mark_async_signal_handler_wrapper (PTR token) { mark_async_signal_handler ((struct async_signal_handler *) token); } --- 957,963 ---- } void ! mark_async_signal_handler_wrapper (void *token) { mark_async_signal_handler ((struct async_signal_handler *) token); } >From kettenis@wins.uva.nl Fri Mar 03 08:36:00 2000 From: Mark Kettenis To: msnyder@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: lin-thread cannot handle thread exit Date: Fri, 03 Mar 2000 08:36:00 -0000 Message-id: <200003031635.e23GZwi00372@delius.kettenis.local> X-SW-Source: 2000-03/msg00060.html Content-length: 1394 Hi Michael, The thread_db assisted debugging code doesn't handle exiting threads properly, at least in combination with glibc 2.1.3. There are at least two problems that prevent this from working: 1. In lin-thread.c:enable_thread_event_reporting(), GDB requests TD_DEATH events to be reported, and sets a breakpoint at the appropriate location. The problem is that the LinuxThreads implementation included with glibc 2.1.3 triggers that breakpoint after it has flagged the thread as terminated. As a conseuqence when GDB tries to fetch the registers for that thread it doesn't succeed, and GDB complains about a breakpoint at location 0x0 that it doesn't know of. 2. If I disable the reporting of TD_DEATH events, things still don't work. The problem is that when the thread really exits, a TARGET_WAITKIND_EXITED event is reported to GDB in. So the answer to the question ``Can I get this event mistakenly from a thread?'' in lin-thread.c:thread_db_wait() is ``Yes''. Since the TARGET_WAITKIND_EXITED event is passed on to other code in GDB, GDB thinks that the entire process has died. Ignoring those "spurious" TARGET_WAITKIND_EXITED events doesn't help since some parts of GDB still think that the thread is still alive then. Looking through the code, it seems that there quite a few "loose ends". Is this still "work in progress"? Mark