* Re: RDI target broken in 000215 snapshot [not found] ` <38B2AD14.7B0B4A4E@redhat.com> @ 2000-02-24 10:47 ` Grant Edwards 2000-04-01 0:00 ` Fernando Nasser 2000-04-01 0:00 ` Grant Edwards 1 sibling, 1 reply; 6+ messages in thread From: Grant Edwards @ 2000-02-24 10:47 UTC (permalink / raw) To: Fernando Nasser; +Cc: gdb On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote: > > The RDI target support seems to be broken in the 000215 > > snapshot. > > Can you be more specific? It is working right with the AEB board and > with another one I have here. Both use serial ports. (I'm now using 000222) When I download code with the "load" command, the byte order of the data gets flipped -- it ends up in little-endian order (it's big-endian in the file, and I need it to stay that way when it is downloaded). Downloading with a patched 4.18 doesn't have this problem. -- Grant Edwards grante@visi.com From fnasser@cygnus.com Thu Feb 24 11:16:00 2000 From: Fernando Nasser <fnasser@cygnus.com> To: Grant Edwards <grante@visi.com> Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 11:16:00 -0000 Message-id: <38B58292.3B11D622@cygnus.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> X-SW-Source: 2000-02/msg00007.html Content-length: 1221 Grant Edwards wrote: > > On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote: > > > > The RDI target support seems to be broken in the 000215 > > > snapshot. > > > > Can you be more specific? It is working right with the AEB board and > > with another one I have here. Both use serial ports. > > (I'm now using 000222) > > When I download code with the "load" command, the byte order of > the data gets flipped -- it ends up in little-endian order > (it's big-endian in the file, and I need it to stay that way > when it is downloaded). Downloading with a patched 4.18 doesn't > have this problem. > Grant, A few questions (while I rebuild from the 22 sources): What compiler, in what host and with which parameters did you generate your executable file? Is it the same one you can successifuly load with the patched 4.18? In both cases you are loading the program into the AEB board, right? I forgot, which host are you running gdb in? Linux, Solaris, Cygwin? Thanks, Fernando -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From grante@visi.com Thu Feb 24 11:33:00 2000 From: Grant Edwards <grante@visi.com> To: Fernando Nasser <fnasser@cygnus.com> Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 11:33:00 -0000 Message-id: <20000224133238.A723@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> X-SW-Source: 2000-02/msg00008.html Content-length: 1495 On Thu, Feb 24, 2000 at 02:12:18PM -0500, Fernando Nasser wrote: > > When I download code with the "load" command, the byte order of > > the data gets flipped -- it ends up in little-endian order > > (it's big-endian in the file, and I need it to stay that way > > when it is downloaded). Downloading with a patched 4.18 doesn't > > have this problem. > > > Grant, > > What compiler, in what host and with which parameters did you > generate your executable file? $ uname -a Linux grante.comtrol.com 2.2.12-20 #1 Mon Sep 27 10:25:54 EDT 1999 i586 unknown $ arm-elf-gcc --version 2.95.2 $ arm-elf-as --version GNU assembler 991018 $ make arm-elf-as --gstabs -EB -m arm7tdmi -amhlsnd=memconfigR10_S0_D100.lst -o memconfigR10_S0_D100.o memconfigR10_S0_D100.s arm-elf-gcc -g -mcpu=arm7tdmi -fverbose-asm -mbig-endian -Wl,-Map,memconfigR10_S0_D100.map -nostartfiles -o memconfigR10_S0_D100 memconfigR10_S0_D100.o -T./memconfig.ld -nostdlib libgcc.a > Is it the same one you can successifuly load with the patched 4.18? Yes. > In both cases you are loading the program into the AEB board, right? No. I'm loading to custom hardware (big-endian), but I verified that the same thing happens with the Samsung SNDS eval board (also big-endian hardware). I've used the EPI Jeeni (via ethernet) and the ARM Embedded ICE (via serial port) and had the same results. > I forgot, which host are you running gdb in? Linux, Solaris, Cygwin? Linux (same as above). -- Grant Edwards grante@visi.com From grante@visi.com Thu Feb 24 11:46:00 2000 From: Grant Edwards <grante@visi.com> To: Fernando Nasser <fnasser@cygnus.com> Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 11:46:00 -0000 Message-id: <20000224134607.A6354@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> X-SW-Source: 2000-02/msg00009.html Content-length: 984 Another interesting bit of info. The new snapshot is apparently not detecting the endianness of the target (both the sessions below were with a Samsung SNDS evel board (big-endian): $ arm-elf-gdb GNU gdb 4.18 [...] This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". (gdb) target rdi /dev/ttyS1 EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) Rebuilt on Apr 1 1998 at 00:43:57 Serial Rate: 9600 Connected to ARM RDI target. (gdb) show endian The target endianness is set automatically (currently big endian) $ ~/gdb-000222/gdb/gdb GNU gdb 000222 [...] This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". (gdb) target rdi /dev/ttyS1 EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) Rebuilt on Apr 1 1998 at 00:43:57 Serial Rate: 9600 Connected to ARM RDI target. (gdb) show endian The target endianness is set automatically (currently little endian) -- Grant ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RDI target broken in 000215 snapshot 2000-02-24 10:47 ` RDI target broken in 000215 snapshot Grant Edwards @ 2000-04-01 0:00 ` Fernando Nasser [not found] ` <20000224134607.A6354@visi.com> 0 siblings, 1 reply; 6+ messages in thread From: Fernando Nasser @ 2000-04-01 0:00 UTC (permalink / raw) To: Grant Edwards; +Cc: Fernando Nasser, gdb Grant Edwards wrote: > > On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote: > > > > The RDI target support seems to be broken in the 000215 > > > snapshot. > > > > Can you be more specific? It is working right with the AEB board and > > with another one I have here. Both use serial ports. > > (I'm now using 000222) > > When I download code with the "load" command, the byte order of > the data gets flipped -- it ends up in little-endian order > (it's big-endian in the file, and I need it to stay that way > when it is downloaded). Downloading with a patched 4.18 doesn't > have this problem. > Grant, A few questions (while I rebuild from the 22 sources): What compiler, in what host and with which parameters did you generate your executable file? Is it the same one you can successifuly load with the patched 4.18? In both cases you are loading the program into the AEB board, right? I forgot, which host are you running gdb in? Linux, Solaris, Cygwin? Thanks, Fernando -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Jim Kingdon <kingdon@redhat.com> Cc: gdb@sourceware.cygnus.com Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C22262.FFA0191@cygnus.com> References: <38BC81A0.17D25C8@cygnus.com> <bbt4y3s8k.fsf@rtl.cygnus.com> <38BE146B.46ED6E4D@cygnus.com> <200003021446.JAA31093@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00546.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 eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii <eliz@delorie.com> To: ezannoni@cygnus.com Cc: muller@cerbere.u-strasbg.fr, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Buffering problems with "gdb < foo" Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003080948.EAA16456@indy.delorie.com> References: <200003070845.JAA27855@cerbere.u-strasbg.fr> <200003070851.DAA14463@indy.delorie.com> <14533.8241.716311.478074@kwikemart.cygnus.com> X-SW-Source: 2000-q1/msg00593.html Content-length: 2259 > This input_from_terminal_p() function does: > > int > input_from_terminal_p () > { > return gdb_has_a_terminal () && (instream == stdin) & caution; > } > > In my case the gdb_has_a_terminal() returns 0, so the query is not asked. > > All seems to work fine fro solaris. What happens on DJGPP? Is > gdb_has_a terminal() returning 1, maybe? Yes, gdb_has_a_terminal returned 1 in the DJGPP case. This turned to be due to a problem in ser-go32.c: it doesn't support standard handles (those which are connected to a terminal in an interactive session), whereas GDB expects it to. I don't know why does gdb_has_a_terminal go through serial.c to find out about GDB's own the controlling terminal--won't it be easier (and more portable) just to use isatty? Anyway, the patch to make the current code in gdb_has_a_terminal work is below. 2000-03-07 Eli Zaretskii <eliz@is.elta.co.il> * ser-go32.c (dos_get_tty_state): Fail if the (fake) handle was not opened by dos_open, but let the 3 standard handles go through unharmed. --- gdb/ser-go32.c~0 Wed Feb 23 17:18:50 2000 +++ gdb/ser-go32.c Tue Mar 7 22:19:34 2000 @@ -488,6 +488,10 @@ dos_open (scb, name) return -1; } + /* FIXME: this is a Bad Idea (tm)! One should *never* invent file + handles, since they might be already used by other files/devices. + The Right Way to do this is to create a real handle by dup()'ing + some existing one. */ fd = name[3] - '1'; port = &ports[fd]; if (port->refcnt++ > 0) @@ -650,6 +654,19 @@ dos_get_tty_state (scb) struct dos_ttystate *port = &ports[scb->fd]; struct dos_ttystate *state; + /* Are they asking about a port we opened? */ + if (port->refcnt <= 0) + { + /* We've never heard about this port. We should fail this call, + unless they are asking about one of the 3 standard handles, + in which case we pretend the handle was open by us if it is + connected to a terminal device. This is beacuse Unix + terminals use the serial interface, so GDB expects the + standard handles to go through here. */ + if (scb->fd >= 3 || !isatty (scb->fd)) + return NULL; + } + state = (struct dos_ttystate *) xmalloc (sizeof *state); *state = *port; return (serial_ttystate) state; ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20000224134607.A6354@visi.com>]
* Re: RDI target broken in 000215 snapshot [not found] ` <20000224134607.A6354@visi.com> @ 2000-02-24 12:01 ` Fernando Nasser [not found] ` <38B59CE1.4CFA7F1E@cygnus.com> 1 sibling, 0 replies; 6+ messages in thread From: Fernando Nasser @ 2000-02-24 12:01 UTC (permalink / raw) To: Grant Edwards; +Cc: Fernando Nasser, gdb [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 49606 bytes --] Grant Edwards wrote: > > Another interesting bit of info. The new snapshot is apparently not > detecting the endianness of the target (both the sessions below were > with a Samsung SNDS evel board (big-endian): > I guess you got it. Can you set the endianess and do the load after that? Please let me know if it worked. In the meanwhile I will check for differences (my build is still going on :-) Thanks, Fernando > $ arm-elf-gdb > GNU gdb 4.18 > [...] > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". > (gdb) target rdi /dev/ttyS1 > EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) > Rebuilt on Apr 1 1998 at 00:43:57 > Serial Rate: 9600 > Connected to ARM RDI target. > (gdb) show endian > The target endianness is set automatically (currently big endian) > > > $ ~/gdb-000222/gdb/gdb > GNU gdb 000222 > [...] > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". > (gdb) target rdi /dev/ttyS1 > EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) > Rebuilt on Apr 1 1998 at 00:43:57 > Serial Rate: 9600 > Connected to ARM RDI target. > (gdb) show endian > The target endianness is set automatically (currently little endian) > > -- > Grant -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From grante@visi.com Thu Feb 24 12:16:00 2000 From: Grant Edwards <grante@visi.com> To: Fernando Nasser <fnasser@cygnus.com> Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 12:16:00 -0000 Message-id: <20000224141648.A1896@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B58DAE.9CAA0A59@cygnus.com> X-SW-Source: 2000-02/msg00011.html Content-length: 385 > > > Another interesting bit of info. The new snapshot is apparently not > > detecting the endianness of the target (both the sessions below were > > with a Samsung SNDS evel board (big-endian): > > > I guess you got it. > > Can you set the endianess and do the load after that? Yes. If I set endian to big, then code gets downloaded properly. -- Grant Edwards grante@visi.com From fnasser@cygnus.com Thu Feb 24 13:06:00 2000 From: Fernando Nasser <fnasser@cygnus.com> To: Grant Edwards <grante@visi.com> Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 13:06:00 -0000 Message-id: <38B59CE1.4CFA7F1E@cygnus.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> X-SW-Source: 2000-02/msg00012.html Content-length: 2553 > > > > > Another interesting bit of info. The new snapshot is apparently not > > > detecting the endianness of the target (both the sessions below were > > > with a Samsung SNDS evel board (big-endian): > > > > > > I guess you got it. > > > > Can you set the endianess and do the load after that? > > Yes. If I set endian to big, then code gets downloaded properly. > > -- > Grant Edwards > grante@visi.com At least you have a way to work now. Just add a .gdbinit with the set endian command on your project directory (the one you want to be big endian). We can now, with less pressure, discuss what is going on. The default for arm targets is "selectable" and "little endian". This is introduced in december by Stan, who checked in a patch from Scott. The ChangeLog fails to mention this change!!! But cvs diff never lies... ;-) I believe the ideal scenario would be to have this thing set in a "smart" way. The current RDI code just ignores the endianess indication returned by the target. Maybe we could use that to set the endianess (only if "auto" is selected, please) of the target. I don't know if this will work, but I can try when I get back. Of course, you can try that yourself and submit a patch :-) The interesting line is in remote-rdi.c:279 Cheers, Fernando Grant Edwards wrote: > > Another interesting bit of info. The new snapshot is apparently not > detecting the endianness of the target (both the sessions below were > with a Samsung SNDS evel board (big-endian): > > $ arm-elf-gdb > GNU gdb 4.18 > [...] > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". > (gdb) target rdi /dev/ttyS1 > EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) > Rebuilt on Apr 1 1998 at 00:43:57 > Serial Rate: 9600 > Connected to ARM RDI target. > (gdb) show endian > The target endianness is set automatically (currently big endian) > > > $ ~/gdb-000222/gdb/gdb > GNU gdb 000222 > [...] > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". > (gdb) target rdi /dev/ttyS1 > EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) > Rebuilt on Apr 1 1998 at 00:43:57 > Serial Rate: 9600 > Connected to ARM RDI target. > (gdb) show endian > The target endianness is set automatically (currently little endian) > > -- > Grant -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From grante@visi.com Thu Feb 24 13:27:00 2000 From: Grant Edwards <grante@visi.com> To: Fernando Nasser <fnasser@cygnus.com> Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 13:27:00 -0000 Message-id: <20000224152638.A2092@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> X-SW-Source: 2000-02/msg00013.html Content-length: 1248 On Thu, Feb 24, 2000 at 04:04:33PM -0500, Fernando Nasser wrote: > > > > Another interesting bit of info. The new snapshot is apparently not > > > > detecting the endianness of the target (both the sessions below were > > > > with a Samsung SNDS evel board (big-endian): > > > > > > I guess you got it. > > The default for arm targets is "selectable" and "little endian". > This is introduced in december by Stan, who checked in a patch from Scott. > The ChangeLog fails to mention this change!!! But cvs diff never lies... ;-) Nope. > I believe the ideal scenario would be to have this thing set in > a "smart" way. The current RDI code just ignores the endianess > indication returned by the target. Maybe we could use that to > set the endianess (only if "auto" is selected, please) of the > target. I don't know if this will work, but I can try when I > get back. I had assumed that gdb was detecting the endianness of the target already (before today, I didn't know it was user selectable). I'll take a look at make the "auto" mode pay attention to the target hardware indication. One could then generate a warning if the endiannes of the target and the endianness of a file being loaded disagree. -- Grant Edwards grante@visi.com From fnasser@cygnus.com Thu Feb 24 13:44:00 2000 From: Fernando Nasser <fnasser@cygnus.com> To: Grant Edwards <grante@visi.com> Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 13:44:00 -0000 Message-id: <38B5A5D1.B2C0EB96@cygnus.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> X-SW-Source: 2000-02/msg00014.html Content-length: 786 Grant Edwards wrote: > > I had assumed that gdb was detecting the endianness of the > target already (before today, I didn't know it was user > selectable). I'll take a look at make the "auto" mode pay > attention to the target hardware indication. One could then > generate a warning if the endiannes of the target and the > endianness of a file being loaded disagree. > Good idea. If the endianess is set to auto, then you set it appropriately. If not, and it differs from the target, a warning is in order. You got no indication at all that something was wrong. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From grante@visi.com Thu Feb 24 14:18:00 2000 From: Grant Edwards <grante@visi.com> To: Fernando Nasser <fnasser@cygnus.com> Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 14:18:00 -0000 Message-id: <20000224161811.A2505@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> X-SW-Source: 2000-02/msg00015.html Content-length: 617 On Thu, Feb 24, 2000 at 03:26:38PM -0600, Grant Edwards wrote: > I had assumed that gdb was detecting the endianness of the > target already (before today, I didn't know it was user > selectable). I'll take a look at makeing the "auto" mode pay > attention to the target hardware indication. Does the Angel monitor report the current hardware status correctly? The EPI Jeeni correctly reports my target is big-endian, but the ARM EmbeddedICE reports that it is little. Unless most targets correctly report correct endian status, it's probably not worth paying attention to it. -- Grant Edwards grante@visi.com From bgat@usa.net Thu Feb 24 14:44:00 2000 From: William A.Gatliff <bgat@usa.net> To: gdb@sourceware.cygnus.com Subject: gdb configure core dumps Date: Thu, 24 Feb 2000 14:44:00 -0000 Message-id: <20000224224408.2947.qmail@nwcst283.netaddress.usa.net> X-SW-Source: 2000-02/msg00016.html Content-length: 474 Guys: I'm trying to configure gdb-4.18 on a fresh install of RH6.1, and it isn't working. It seems as though no matter what I supply for arguments to configure (including no arguments at all), I always get back the same thing as if I had typed --help, and a core file appears in the directory. Any ideas? I'm stumped... b.g. ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From echristo@cygnus.com Thu Feb 24 15:24:00 2000 From: Eric Christopher <echristo@cygnus.com> To: "William A.Gatliff" <bgat@usa.net> Cc: gdb@sourceware.cygnus.com Subject: Re: gdb configure core dumps Date: Thu, 24 Feb 2000 15:24:00 -0000 Message-id: <38B5BDDF.6E73AEF4@cygnus.com> References: <20000224224408.2947.qmail@nwcst283.netaddress.usa.net> X-SW-Source: 2000-02/msg00017.html Content-length: 286 > It seems as though no matter what I supply for arguments to configure > (including no arguments at all), I always get back the same thing as if I had > typed --help, and a core file appears in the directory. > What does 'file core' say? Perhaps there is some issue with sh? -eric From hanymorcos@yahoo.com Thu Feb 24 15:27:00 2000 From: Hany Morcos <hanymorcos@yahoo.com> To: gdb@sourceware.cygnus.com Subject: Debugging a constructor Date: Thu, 24 Feb 2000 15:27:00 -0000 Message-id: <20000224232705.13750.qmail@web3207.mail.yahoo.com> X-SW-Source: 2000-02/msg00018.html Content-length: 431 How do I print the variable values inside a constructor? I can't use this... Because doesn't exist yet.. The object hasn't been constructed... Then how do I print the value of x?? class y{ public: y(int* x) {x = coreDumpAndGenerateManyHeadaches(); // print x inside gdb } ; }; __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From hanymorcos@yahoo.com Thu Feb 24 16:31:00 2000 From: Hany Morcos <hanymorcos@yahoo.com> To: Hany Morcos <hanymorcos@yahoo.com>, gdb@sourceware.cygnus.com Subject: Re: Debugging a constructor Date: Thu, 24 Feb 2000 16:31:00 -0000 Message-id: <20000225003041.21219.qmail@web3204.mail.yahoo.com> X-SW-Source: 2000-02/msg00019.html Content-length: 686 Got it thank you --- Hany Morcos <hanymorcos@yahoo.com> wrote: > > > How do I print the variable values inside > a constructor? > > I can't use this... Because doesn't exist yet.. > The object hasn't been constructed... > > Then how do I print the value of x?? > > class y{ > > public: > y(int* x) {x = > coreDumpAndGenerateManyHeadaches(); // print x > inside > gdb } ; > }; > > > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From ac131313@cygnus.com Thu Feb 24 18:55:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Fernando Nasser <fnasser@cygnus.com> Cc: Grant Edwards <grante@visi.com>, Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 18:55:00 -0000 Message-id: <38B5EEDB.8A8F2DD8@cygnus.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> X-SW-Source: 2000-02/msg00020.html Content-length: 2275 FYI, The current behavior is determined by gdbarch.c: o it starts in auto mode using TARGET_BYTE_ORDER_DEFAULT as an initial value or (chosen arbitrarily) BIG_ENDIAN as the next best guess. o as soon as GDB encounters a binary it pokes around the bfd file to determine the endianess and uses that (provided things are still auto). To the best of my knowledge, no one has seriously investigated how to set up an interface where the target determines architectural information (such as endianess). As for the current problem: $ arm-elf-gdb GNU gdb 4.18 [...] This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". (gdb) target rdi /dev/ttyS1 EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) Rebuilt on Apr 1 1998 at 00:43:57 Serial Rate: 9600 Connected to ARM RDI target. (gdb) show endian The target endianness is set automatically (currently big endian) $ ~/gdb-000222/gdb/gdb GNU gdb 000222 [...] This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". (gdb) target rdi /dev/ttyS1 EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) Rebuilt on Apr 1 1998 at 00:43:57 Serial Rate: 9600 Connected to ARM RDI target. (gdb) show endian The target endianness is set automatically (currently little endian) it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the wrong place. enjoy, Andrew Fernando Nasser wrote: > > Grant Edwards wrote: > > > > I had assumed that gdb was detecting the endianness of the > > target already (before today, I didn't know it was user > > selectable). I'll take a look at make the "auto" mode pay > > attention to the target hardware indication. One could then > > generate a warning if the endiannes of the target and the > > endianness of a file being loaded disagree. > > > Good idea. If the endianess is set to auto, then you set it appropriately. > If not, and it differs from the target, a warning is in order. > You got no indication at all that something was wrong. > > -- > Fernando Nasser > Red Hat - Toronto E-Mail: fnasser@cygnus.com > 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 > Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From ac131313@cygnus.com Thu Feb 24 19:35:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Mark Kettenis <kettenis@wins.uva.nl> Cc: kevinb@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Patches for GNU/Linux PPC native now in CVS Date: Thu, 24 Feb 2000 19:35:00 -0000 Message-id: <38B5F82F.D4C46B90@cygnus.com> References: <1000222025201.ZM9805@ocotillo.lan> <200002221013.e1MAD3A00261@delius.kettenis.local> <1000224102541.ZM14031@ocotillo.lan> <200002241047.LAA02405@landau.wins.uva.nl> X-SW-Source: 2000-02/msg00021.html Content-length: 1318 Mark Kettenis wrote: > > Date: Thu, 24 Feb 2000 03:25:41 -0700 > From: Kevin Buettner <kevinb@cygnus.com> > > On Feb 22, 11:13am, Mark Kettenis wrote: > > [Detailed failure analysis snipped] > > > Anyway, I hope this helps, > > It did indeed. Thanks! (It showed me where not to focus my attention > first.) > > I'll respond to the sourceware list when I've had more time to study > your analysis, but in the meantime, I wanted to send you a note to let > you know that I appreciated your analysis... > > Meanwhile, I learned something more about the > > gdb.base/annota1.exp: backtrace @ signal handler > > failure I reported. There is nothing wrong with the test per se. > It's just that on my i586-pc-linux-gnu system the regexp matching > takes an awful lot of time. Setting the timeout to 10 minutes made > the test pass. This is probably related to the fact that with glibc > there is an extra frame. Apparently the fix I suggested (but didn't > understand), speeded up the regexp matching somewhat, but even in that > case (with the default timeout) the test failed on my system last > night. Have a look at gdb.base/call-ar-st.exp and how it used ``gdb_expect_list''. Patches that make the testsuite run 10 minutes faster are always more than welcome :-) Andrew From grante@visi.com Thu Feb 24 19:57:00 2000 From: Grant Edwards <grante@visi.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: Fernando Nasser <fnasser@cygnus.com>, Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 19:57:00 -0000 Message-id: <20000224215652.A7650@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B5EEDB.8A8F2DD8@cygnus.com> X-SW-Source: 2000-02/msg00022.html Content-length: 801 > o as soon as GDB encounters a binary > it pokes around the bfd file to determine > the endianess and uses that (provided things > are still auto). That implies that when I loaded a big-endian file it should have switched to big-endian. It didn't seem to -- I'll have to try that again. > To the best of my knowledge, no one has seriously investigated how to > set up an interface where the target determines architectural > information (such as endianess). Since 50% of my sample of 2 target interfaces don't correctly report endianess, it may not be something worth investigating. > it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the > wrong place. Now that I know what happened, it's not a big deal. I can just set it in .gdbinit. -- Grant Edwards grante@visi.com From ac131313@cygnus.com Thu Feb 24 22:11:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Grant Edwards <grante@visi.com> Cc: Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Thu, 24 Feb 2000 22:11:00 -0000 Message-id: <38B61CF6.B4F80802@cygnus.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> X-SW-Source: 2000-02/msg00023.html Content-length: 1084 Grant Edwards wrote: > > > o as soon as GDB encounters a binary > > it pokes around the bfd file to determine > > the endianess and uses that (provided things > > are still auto). > > That implies that when I loaded a big-endian file it should have > switched to big-endian. It didn't seem to -- I'll have to try that > again. Possibly not. If you were using: (gdb) load file-with-random-format then GDB won't look at the file. I should have said that something like gdb sets the endianess once the debug file is specified (via ``file'' or a few other commands) vis: (gdb) file debug-file (gdb) load ``load'' tends to not have side effects (and when it does, they are hotly debated :-) > > it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the > > wrong place. > > Now that I know what happened, it's not a big deal. I can just set it > in .gdbinit. It's more a question of should the endianess have changed between releases or should it have been little-endian anyway. Not my problem :-) Andrew From fnasser@redhat.com Fri Feb 25 07:08:00 2000 From: Fernando Nasser <fnasser@redhat.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: Grant Edwards <grante@visi.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Fri, 25 Feb 2000 07:08:00 -0000 Message-id: <38B69A2A.ED2DC6F3@redhat.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com> X-SW-Source: 2000-02/msg00024.html Content-length: 962 Andrew Cagney wrote: > > It's more a question of should the endianess have changed between > releases or should it have been little-endian anyway. Not my problem > :-) > I inherited this one :-) But you are right, this will at least require an entry in the NEWS, as it alters some previous behavior. *If* the arm users in the list decide that the default should be little-endian. It does seem reasonable and if the file command straights it out, only the load users would have to care (but they are more aware of these issues, and can always have the set endian on their .gdbinit). It is a shame that Angel is so buggy. The return code should appropriately indicate the endianess of the target -- it would be a nice feature to use :-( -- Fernando Nasser Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From grante@visi.com Fri Feb 25 07:14:00 2000 From: Grant Edwards <grante@visi.com> To: Fernando Nasser <fnasser@redhat.com> Cc: Andrew Cagney <ac131313@cygnus.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Fri, 25 Feb 2000 07:14:00 -0000 Message-id: <20000225091418.B3106@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com> <38B69A2A.ED2DC6F3@redhat.com> X-SW-Source: 2000-02/msg00025.html Content-length: 1379 On Fri, Feb 25, 2000 at 03:05:14PM +0000, Fernando Nasser wrote: > > It's more a question of should the endianess have changed between > > releases or should it have been little-endian anyway. Not my problem > > :-) > > I inherited this one :-) > > But you are right, this will at least require an entry in the > NEWS, as it alters some previous behavior. *If* the arm users > in the list decide that the default should be little-endian. From what I've seen/read little-endian is more common (does ARM-Linux run little-endian or big?), and it's the default for gcc/binutils, so it should probably be the default for gdb as well. I was just confused because I thought "auto" meant that it would be determined by the target. > It does seem reasonable and if the file command straights it > out, only the load users would have to care (but they are more > aware of these issues, and can always have the set endian on > their .gdbinit). Having the load command warn the user if the target and file differ might also be something to consider. > It is a shame that Angel is so buggy. The return code should > appropriately indicate the endianess of the target -- it would > be a nice feature to use :-( Does Angel not report it correctly? The ARM EmbeddedICE is broken in that respect, but I don't have a copy of Angel running anywhere. -- Grant Edwards grante@visi.com From fnasser@redhat.com Fri Feb 25 07:29:00 2000 From: Fernando Nasser <fnasser@redhat.com> To: Grant Edwards <grante@visi.com> Cc: Andrew Cagney <ac131313@cygnus.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Fri, 25 Feb 2000 07:29:00 -0000 Message-id: <38B69F56.5ECE30F6@redhat.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com> <38B69A2A.ED2DC6F3@redhat.com> <20000225091418.B3106@visi.com> X-SW-Source: 2000-02/msg00026.html Content-length: 1689 Grant Edwards wrote: > > Having the load command warn the user if the target and file > differ might also be something to consider. > The trick is how to know the target endianess. Also, note that the file being loaded by the load command ay not have this info. The file command is the one that reads files from where this can be determined. > Does Angel not report it correctly? The ARM EmbeddedICE is > broken in that respect, but I don't have a copy of Angel > running anywhere. > My mistake. I thought you made reference to an Angel board on you 50/50 little statistic. I have two little-endian boards running two different versions of Angel. I will check wen I get back. But I guess you are right, we should assume that the target RDI protocol is working properly and check for the endianess. For the boards/devices that are broken, the user will have to turn off the auto mode and set the endianess appropriately on his/her .gdbinit. Another possibility is that we just issue a warning (instead of setting the endianess) based on the result returned from the board. If it is a board/device with a know problem of returning the wrong info, the user will just ignore the warning. To make GUI users happier, he warning would not be issued if auto is turned off (what means that the user set deliberately the endianess so he/she should know what he/she is doing). BTW: AFAIK Linux-arm is little endian, and that is why Stan and Scott changed the default. -- Fernando Nasser Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From scottb@netwinder.org Fri Feb 25 10:11:00 2000 From: Scott Bambrough <scottb@netwinder.org> To: "fnasser@cygnus.com" <fnasser@cygnus.com> Cc: James Ingham <jingham@cygnus.com>, GDB Mailing List <gdb@sourceware.cygnus.com> Subject: bug in arm_push_arguments() Date: Fri, 25 Feb 2000 10:11:00 -0000 Message-id: <38B6C4A1.7A1461C4@netwinder.org> X-SW-Source: 2000-02/msg00027.html Content-length: 4031 Hi guys, I've been looking at this function as there are regressions in gdb.base/callfuncs. In particular I've been looking at this code. /* ANSI C code passes float arguments as integers, K&R code passes float arguments as doubles. The .stabs record for for ANSI prototype floating point arguments records the type as FP_INTEGER, while a K&R style (no prototype) .stabs records the type as FP_FLOAT. In this latter case the compiler converts the float arguments to double before calling the function. */ if (TYPE_CODE_FLT == typecode && REGISTER_SIZE == len) { float f; double d; char * bufo = (char *) &d; char * bufd = (char *) &dbl_arg; len = sizeof (double); f = *(float *) val; SWAP_TARGET_AND_HOST (&f, sizeof (float)); /* adjust endianess */ d = f; /* We must revert the longwords so they get loaded into the the right registers. */ memcpy (bufd, bufo + len / 2, len / 2); SWAP_TARGET_AND_HOST (bufd, len / 2); /* adjust endianess */ memcpy (bufd + len / 2, bufo, len / 2); SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */ val = (char *) &dbl_arg; } I added this particular piece of code to handle functions without prototypes that pass floats as parameters, because the compiler treats them differently. Someone added code which is attempting the following (see my comments): /* The value is in TARGET byte order. Convert it to HOST byte order in preparation for conversion to a double. */ f = *(float *) val; SWAP_TARGET_AND_HOST (&f, sizeof (float)); /* adjust endianess */ /* Convert the float to a double in HOST byte order. */ d = f; /* Convert the double to TARGET byte order and swap things to conform to the ARM floating point layout. */ memcpy (bufd, bufo + len / 2, len / 2); SWAP_TARGET_AND_HOST (bufd, len / 2); /* adjust endianess */ memcpy (bufd + len / 2, bufo, len / 2); SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */ val = (char *) &dbl_arg; This is ok, but the code for the last step is unnecessarily complex. I think something similar to the following should suffice. int tmp, *buf = &d; SWAP_TARGET_AND_HOST (&d, sizeof (double)); tmp = buf[0]; buf[0] = buf[1]; buf[1] = tmp; I think this will result in better code from the compiler. There are a couple of problems though with this code. First what happens if sizeof (TARGET_DOUBLE) != sizeof (HOST_DOUBLE). Second, this breaks in the native case, because the double is already in the right format. This is why I have regressions I believe (I have yet to test my theory). Is there a clean way to solve these problems? I also noticed this comment while investigating. I disabled the code when I rewrote the function. I didn't know what it was for, and I wasn't sure it should stay. I left it for Stan and Jim to evaluate. If it is necessary I would document what it does and why it does it, and get rid of question. In particular why is setting the mode bit fine? #if 1 /* I don't know why this code was disable. The only logical use for a function pointer is to call that function, so setting the mode bit is perfectly fine. FN */ /* If the argument is a pointer to a function, and it is a Thumb function, set the low bit of the pointer. */ if (TYPE_CODE_PTR == typecode && NULL != target_type && TYPE_CODE_FUNC == TYPE_CODE (target_type)) { CORE_ADDR regval = extract_address (val, len); if (arm_pc_is_thumb (regval)) store_address (val, len, MAKE_THUMB_ADDR (regval)); } #endif Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org From jimb@cygnus.com Fri Feb 25 10:27:00 2000 From: Jim Blandy <jimb@cygnus.com> To: gdb@sourceware.cygnus.com Subject: patch database proposal Date: Fri, 25 Feb 2000 10:27:00 -0000 Message-id: <200002251827.NAA09955@zwingli.cygnus.com> X-SW-Source: 2000-02/msg00028.html Content-length: 8847 Here's a tentative proposal for how the patch database should work. In reality, a good part of this is set up and ready to go, but there's nothing we can't revise, in the presence of good ideas or persuasive criticism. Please let me know what you think; post your comments to the list. ---- If you've written a patch for GDB, either to fix a bug or to improve the program, you should make sure it gets into the GDB patch database. The GDB patch database is a GNATS database created to help GDB's maintainers keep track of patches that need reviewing, and helps you stay on top of what's happening to your patch. Anyone can submit a patch. There are two ways to do so: - Visit the GDB Patch Submission page [Jason will supply URL], and submit your patch there. - Submit your patches via E-mail, by sending a message to `gdb-patches-gnats@sourceware.cygnus.com'. We have a template for mail messages [link here]. Following this template helps make sure we have the information we need to choose a reviewer for your patch, and to do the review itself. We'd prefer that you use the web form, if possible, because that provides more helpful prompts, and checks your input more thoroughly. The database assigns each new patch a number, like `gdb-patch/209'. Whenever you send mail regarding your patch, be sure to include the address `gdb-patches-gnats@sourceware.cygnus.com' in the CC list, and make sure the message subject starts with `gdb-patch/209: ', or whatever your patch number is. This way, GNATS will automatically log the discussion along with the patch in the database. Once you've submitted your patch, you can visit [another URL] to check on its status, or to search the patch database in various ways. Each patch in the database has a set of headers, much like a mail message; the two most interesting headers to look at are: - `Responsible' --- this is the name of the person currently responsible for moving the patch forward. - `State' --- the current status of the patch. Here are the different states a patch might be in: - `unclaimed' If the database software can't figure out automatically which maintainer should evaluate your patch, then it declares the patch `unclaimed', and sets the `Responsible' person to the GDB patch secretary. It is then the secretary's job to find someone who can review the patch, and change the patch's `State' and `Responsible' headers appropriately. Also, if the maintainer responsible for a patch decides that they can't process it --- for example, they might know they won't be able to evaluate it promptly --- then they can put it back in the `unclaimed' state. As before, the patch secretary should find someone else to tend to it. The patch database logs all changes to a patch's state or responsible party, along with all mail communication about the patch, which can help the new person pick the patch where it left off. - `claimed' The person named in the patch's `Responsible' header has volunteered or been designated to review the patch, but they haven't made any decision about it yet, or they haven't gotten around to looking at it yet. The maintainer indicates his or her decision by putting the patch in one of the states below. If the patch requires additional maintainers' approval, then the maintainer should leave the patch in the `claimed' state, and simply change the `Responsible' field to the next maintainer in line. Since all changes in responsibility are logged with the patch, each maintainer can tell when the review process is complete. The last maintainer to evaluate the patch should actually change the state to something more conclusive. As the name suggests, patch claims are voluntary. Maintainers should feel free to claim interesting unclaimed patches for themselves, and to trade or reallocate patches amongst themselves as appropriate, simply by changing patches' `State' and `Responsible' headers. Assignments made automatically by the database software, or manually by the patch secretary, are simply an optimization, meant to help the process run more smoothly. Of course, if a maintainer consistently fails to review patches in a timely fashion, the team will eventually suggest that they step down, or share the responsibility with someone more responsive. - `feedback' This state indicates that the maintainer feels the patch needs revision, or that the author's intent is unclear and the patch should be further explained. It is now the responsibility of the original author of the patch to satisfy the maintainer's concerns, to allow the patch to move forward. The maintainer's concerns should always be recorded with the patch somehow, either in a mail message logged with the patch, or in the state change message. Note that the maintainer is still responsible for patches in this state. If the author is slow to respond, the maintainer must pursue the matter, or put the patch in the `rejected' state (described below) if the author doesn't reply. - `prereqs' The maintainer approves of the patch, but can't apply it until some other change is made --- some other patch must be applied first, for example. The maintainer should explain what they are waiting for in the patch record. It is the maintainer's responsibility to notice when the prerequisites have been met, and move the patch along. - `accepted' The maintainer has decided to apply the patch, and has accepted responsibility for whatever further work is necessary to get it into the sources. - `applied' The maintainer has applied the patch, and expects no further work on that patch to be necessary. - `rejected' This state represents several possible outcomes: - The maintainer has decided that the patch should not be applied, and is not expecting to do revisions or further work on that patch. - The patch's author has withdrawn it, and the maintainer agrees. - The patch is actually several smaller changes lumped together; the author must resubmit it as several separate patches. - The patch is so old that it is no longer useful in revising the current sources, and neither the author nor the maintainer has any intention of bringing it up to date. In any case, the maintainer should explain why the patch was rejected, in the patch notes. Of course, it is always possible for a maintainer to resurrect a rejected patch, simply by putting it back in one of the other states. - `papers' The maintainer would like to apply the patch, but the patch is large enough that it is automatically copyrighted by the author, and cannot be applied to the GDB sources. In this case, the author needs to assign his or her copyright interest in the patch to the Free Software Foundation; see [link], or the file `gdb/CONTRIBUTE' in the GDB source tree, for details about this. [We'll work in full documentation for the other headers somewhere, but this page is mostly about the process, which is the least obvious part.] If you're interested in monitoring patch activity, you may wish to subscribe to `gdb-patches-prs@sourceware.cygnus.com'. This mailing list receives: - messages announcing newly submitted patches - all discussion about existing patches - messages indicating that a patch has changed state, and why To subscribe, [appropriate instructions or link] If you are having problems using the patch database, send mail to `gdb-patches-secretary@sourceware.cygnus.com'. The patch secretary is responsible for: - the quality of the database (removing spam, getting people to use the headers in a helpful way, making sure all patches are placed in the database [in my experience, every database gets dirty, and there needs to be someone working to counteract entropy]); - passing `unclaimed' patches to willing and appropriate maintainers; - all GDB-specific documentation and web pages supporting the patch database; and - any other administration specific to the GDB patch database The patch secretary is not responsible for: - technical issues (like evaluating patches); - administration of shared sourceware infrastructure, not specific to the GDB database (fixing wedged servers, upgrading software, etc.); or - prodding unresponsive maintainers. (General community pressure is best for this; beyond that, the prodding needs to be done by someone with real authority over their time, like their manager, or authority over their maintainership, like the committee that made them a maintainer in the first place.) In the GDB source tree, the file gdb/MAINTAINERS lists the current patch secretary, along with all the maintainers and the areas they're responsible for. From kevinb@cygnus.com Fri Feb 25 11:08:00 2000 From: Kevin Buettner <kevinb@cygnus.com> To: Scott Bambrough <scottb@netwinder.org> Cc: GDB Mailing List <gdb@sourceware.cygnus.com> Subject: Re: bug in arm_push_arguments() Date: Fri, 25 Feb 2000 11:08:00 -0000 Message-id: <1000225190817.ZM16382@ocotillo.lan> References: <38B6C4A1.7A1461C4@netwinder.org> <scottb@netwinder.org> X-SW-Source: 2000-02/msg00029.html Content-length: 3099 On Feb 25, 1:06pm, Scott Bambrough wrote: > /* ANSI C code passes float arguments as integers, K&R code > passes float arguments as doubles. The .stabs record for > for ANSI prototype floating point arguments records the > type as FP_INTEGER, while a K&R style (no prototype) > .stabs records the type as FP_FLOAT. In this latter case > the compiler converts the float arguments to double before > calling the function. */ > if (TYPE_CODE_FLT == typecode && REGISTER_SIZE == len) > { > float f; > double d; > char * bufo = (char *) &d; > char * bufd = (char *) &dbl_arg; > > len = sizeof (double); > f = *(float *) val; > SWAP_TARGET_AND_HOST (&f, sizeof (float)); /* adjust endianess */ > d = f; > /* We must revert the longwords so they get loaded into the > the right registers. */ > memcpy (bufd, bufo + len / 2, len / 2); > SWAP_TARGET_AND_HOST (bufd, len / 2); /* adjust endianess */ > memcpy (bufd + len / 2, bufo, len / 2); > SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */ > val = (char *) &dbl_arg; > } > > I added this particular piece of code to handle functions without prototypes > that pass floats as parameters, because the compiler treats them differently. > Someone added code which is attempting the following (see my comments): > > /* The value is in TARGET byte order. Convert it to HOST byte > order in preparation for conversion to a double. */ > f = *(float *) val; > SWAP_TARGET_AND_HOST (&f, sizeof (float)); /* adjust endianess */ > > /* Convert the float to a double in HOST byte order. */ > d = f; > > /* Convert the double to TARGET byte order and swap things to > conform to the ARM floating point layout. */ > memcpy (bufd, bufo + len / 2, len / 2); > SWAP_TARGET_AND_HOST (bufd, len / 2); /* adjust endianess */ > memcpy (bufd + len / 2, bufo, len / 2); > SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */ > val = (char *) &dbl_arg; > > This is ok, but the code for the last step is unnecessarily complex. I think > something similar to the following should suffice. > > int tmp, *buf = &d; > SWAP_TARGET_AND_HOST (&d, sizeof (double)); > tmp = buf[0]; > buf[0] = buf[1]; > buf[1] = tmp; > > I think this will result in better code from the compiler. There are a couple > of problems though with this code. First what happens if sizeof (TARGET_DOUBLE) > != sizeof (HOST_DOUBLE). Second, this breaks in the native case, because the > double is already in the right format. This is why I have regressions I believe > (I have yet to test my theory). Is there a clean way to solve these problems? It seems to me that you should be able to use store_floating() to do what you want. It'll handle both the conversion and the byte swapping. Kevin From jtc@redback.com Fri Feb 25 17:04:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: command error handling Date: Fri, 25 Feb 2000 17:04:00 -0000 Message-id: <5mr9e093zj.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-02/msg00030.html Content-length: 1257 The CLI for the memory region attributes feature I'm working on is based on displays. Each memory region created is assigned a number, and can be enabled, disabled, and deleted. While stealing the display CLI code, I noticed that when you enable or disable a non-extant display, a message will be output with printf_- unfiltered(), but when you do the same thing with delete, GDB calls error(). The same thing occurs when you attempt to enable/disable/ delete displays with a non-numeric argument. I'll argue that delete should behave like enable and disable, that a message be output and execution should continue. The problem with error(), IMHO, is that it's very heavy handed. While it allows us to avoid the fun of propagating errors up from the lowest levels of GDB, it also makes it impossible for user defined functions to detect the failure of a command (that, plus the fact that there are no command return values, but that's easily remedied by comparision). Without such a mechanism, the usefulness of scripting is greatly diminished. I would expect it to much be the same for all extension languages that may be bound into GDB. Is this a (long-term) direction we should be investigating? --jtc -- J.T. Conklin RedBack Networks From kingdon@redhat.com Sat Feb 26 10:30:00 2000 From: Jim Kingdon <kingdon@redhat.com> To: gdb@sourceware.cygnus.com Subject: Re: command error handling Date: Sat, 26 Feb 2000 10:30:00 -0000 Message-id: <b7lfr6cpc.fsf@rtl.cygnus.com> References: <5mr9e093zj.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-02/msg00031.html Content-length: 1005 > I'll argue that delete should behave like enable and disable, that a > message be output and execution should continue. Sounds good to me. > The problem with error(), IMHO, is that it's very heavy handed. While > it allows us to avoid the fun of propagating errors up from the lowest > levels of GDB, it also makes it impossible for user defined functions > to detect the failure of a command Well, sometimes the command will fail in its entirety. Or to put it another way, some errors you can't continue from, for example, in "delete display foo 4 3 5 2" we might be willing to guess that 4, 3, 5, and 2 are display numbers but in a different case the syntax of the first part has to be right for the last part to make any sense. One can presumably find non-syntactic examples too. I haven't taken a close look at the error() machinery recently and how it would relate to scripting languages, but there should be some way to trap the error() and return it back to the script. From weech@primenet.com Sat Feb 26 21:33:00 2000 From: Brent Weech <weech@primenet.com> To: gdb@sourceware.cygnus.com, cygwin@sourceware.cygnus.com Subject: GDB error 87 under Cygwin Date: Sat, 26 Feb 2000 21:33:00 -0000 Message-id: <4.3.2.20000226214059.00b8f008@pop.primenet.com> X-SW-Source: 2000-02/msg00032.html Content-length: 1728 Where in the world in the Errors.h file that enumerates the error codes coming from GDB? In particular, I am interested in error 87, as shown below: BLACKBOX> gdb h-hcube                                                   GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-cygwin32"...(no debugging symbols found)... (gdb) r Starting program: //e/h-hcube.exe Error creating process //e/h-hcube.exe, (error 87) I'm sure the answer to this question is somewhere on the Cygnus and/or GDB mailing archive, but for the life of me I can't figure out how to get the wonderfully worthless ht://Dig search engine to accept phrase or boolean searches with any accuracy. It has got to be one of the most frustrating search engine software packages I have ever used. For example, try the following: On the Cygwin Project archive, a search for "error 87" set to match all terms or a boolean search for "error and 87" both give 5474 matches. On the same archive, a search for "error" gives (yes, I'm sure you can guess) the same 5474 matches! But on the same archive, a search for "error 193" set to match all terms only gives 21 hits. What gives? A search though many of the "error 87" hits confirms that the string 87 is nowhere in the text or source of the html page. Someone tell me how to do a reliable phrase search of the mail archives. Brent Weech ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <38B59CE1.4CFA7F1E@cygnus.com>]
[parent not found: <20000224152638.A2092@visi.com>]
[parent not found: <38B61CF6.B4F80802@cygnus.com>]
[parent not found: <38B69A2A.ED2DC6F3@redhat.com>]
* Re: RDI target broken in 000215 snapshot [not found] ` <38B69A2A.ED2DC6F3@redhat.com> @ 2000-04-01 0:00 ` Grant Edwards 0 siblings, 0 replies; 6+ messages in thread From: Grant Edwards @ 2000-04-01 0:00 UTC (permalink / raw) To: Fernando Nasser; +Cc: Andrew Cagney, Fernando Nasser, gdb On Fri, Feb 25, 2000 at 03:05:14PM +0000, Fernando Nasser wrote: > > It's more a question of should the endianess have changed between > > releases or should it have been little-endian anyway. Not my problem > > :-) > > I inherited this one :-) > > But you are right, this will at least require an entry in the > NEWS, as it alters some previous behavior. *If* the arm users > in the list decide that the default should be little-endian. From what I've seen/read little-endian is more common (does ARM-Linux run little-endian or big?), and it's the default for gcc/binutils, so it should probably be the default for gdb as well. I was just confused because I thought "auto" meant that it would be determined by the target. > It does seem reasonable and if the file command straights it > out, only the load users would have to care (but they are more > aware of these issues, and can always have the set endian on > their .gdbinit). Having the load command warn the user if the target and file differ might also be something to consider. > It is a shame that Angel is so buggy. The return code should > appropriately indicate the endianess of the target -- it would > be a nice feature to use :-( Does Angel not report it correctly? The ARM EmbeddedICE is broken in that respect, but I don't have a copy of Angel running anywhere. -- Grant Edwards grante@visi.com From dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches) To: gdb@sourceware.cygnus.com Subject: C++ Overload testsuite fixes, need someone to verify Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <hfdx6o2m.fsf@dan.resnet.rochester.edu> X-SW-Source: 2000-q1/msg00786.html Content-length: 413 Can someone verify, that i am correct in thinking you get unexpected failures in gdb.c++/ovldbreak.exp due to "breakpoint info" failures? I have a patch, i just want to make sure it's not me. It appears the source line the test suite expects main to appear on in that file is 49, and main really appears at 48, so the regex to match doesn't work. I diffed the ovldbreak.cc file, and i get no differences. --Dan From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii <eliz@delorie.com> To: gdb@sourceware.cygnus.com Subject: annotate.texi Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003070832.DAA14451@indy.delorie.com> X-SW-Source: 2000-q1/msg00557.html Content-length: 433 Is there any reason why annotate.texi shouldn't be @include'd by gdb.texinfo and be part of the manual? Right now, "set annotate" is not documented at all, and annotate.texi seems to be just what the doctor ordered... And while at that, NEWS seems to be in the need of some work, it doesn't mention many of the new features that already are in the CVS tree. I would like at least to mention the improvements in the DJGPP version. From kevinb@cygnus.com Sat Apr 01 00:00:00 2000 From: Kevin Buettner <kevinb@cygnus.com> To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>, gdb@sourceware.cygnus.com Subject: Re: Patches for GNU/Linux PPC native now in CVS Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <1000224095244.ZM13976@ocotillo.lan> References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> <Franz.Sirl-kernel@lauterbach.com> X-SW-Source: 2000-q1/msg00395.html Content-length: 890 On Feb 22, 11:09pm, Franz Sirl wrote: > >I invite those of you who have Linux/PPC machines to try out these > >changes and let me know how they work. Also, please let me know about > >any problems that you find. > > I've just uploaded an RPM with the current CVS source to > ftp://devel.linuxppc.org/users/fsirl/ so people can easily test it. Thanks. [...] > A quick test of gdb looked very promising, I already installed it as the > default gdb on our build system. What about "info float"? Are you going to > tackle this yourself later or do you want to leave the implementation to > somebody else? If someone else is willing to do the implementation for "info float", I'm willing to integrate the patches. (I rarely have need for "info float", so it may be better if someone else did the implementation.) OTOH, if no one sends me patches, I'll try to get to it eventually. Kevin From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" <hjl@lucon.org> To: "J.T. Conklin" <jtc@redback.com> Cc: Stan Shebs <shebs@apple.com>, gdb-patches@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com> Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000307162127.D485@lucon.org> References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00576.html Content-length: 534 On Tue, Mar 07, 2000 at 04:18:23PM -0800, J.T. Conklin wrote: > >>>>> "hjl" == H J Lu <hjl@valinux.com> writes: > > hjl> 2000-03-07 H.J. Lu <hjl@gnu.org> > hjl> > hjl> * gdb-regex.h: New. Include <regex.h> for glibc 2 and include > hjl> "gnu-regex.h" otherwise. > > If we follow the naming convention we have been using, gdb-regex.h There are gdb-events.c gdb-events.h gdb-events.sh gdb-regex.h gdb-stabs.h. > should be gdb_regex.h. Either way is fine with me. All I want is regex in glibc 2 :-). Any objections? H.J. From scottb@netwinder.org Sat Apr 01 00:00:00 2000 From: Scott Bambrough <scottb@netwinder.org> To: GDB Mailing List <gdb@sourceware.cygnus.com> Subject: GDB configure problem in the new repository... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A41C50.F4E522DD@netwinder.org> X-SW-Source: 2000-q1/msg00222.html Content-length: 1141 Hi, I checked out a GDB tree on a clean system from the new repository using: cvs -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb and attempted to configure using the following directory structure: cvstree/src cvstree/gdb-build cd gdb-build ../src/configure --prefix=/usr I get the following error: checking for Tcl configuration... found /usr/lib/tclConfig.sh checking for Tk configuration... found /usr/lib/tkConfig.sh checking for Tcl private headers. dir=unix... checking for tclInt.h... no configure: error: Can't find Tcl private headers I checked out the entire tree under src on another machine the other day using the same setup and I could configure and build with the following results for a native armv4l-unknown-linux-gnu target on a NetWinder. === gdb Summary === # of expected passes 6296 # of unexpected failures 56 # of unexpected successes 1 # of expected failures 195 # of unresolved testcases 2 # of untested testcases 5 Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org From hjl@valinux.com Sat Apr 01 00:00:00 2000 From: "H . J . Lu" <hjl@valinux.com> To: Kevin Buettner <kevinb@cygnus.com> Cc: GDB <gdb@sourceware.cygnus.com> Subject: Re: Does today's gdb compile on Linux? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000118104731.B7970@valinux.com> References: <20000118100532.A7871@valinux.com> <hjl@valinux.com> <1000118184306.ZM1103@ocotillo.lan> X-SW-Source: 2000-q1/msg00041.html Content-length: 1621 On Tue, Jan 18, 2000 at 11:43:06AM -0700, Kevin Buettner wrote: > On Jan 18, 10:05am, H . J . Lu wrote: > > > I cannot get today's gdb in CVS to compile on Linux/ia32. It failed on > > i386-linux-nat.c: > > > > /work/gnu/import/gdb/gdb/i386-linux-nat.c: In function `supply_fpregset': > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:215: request for member `st_space' in > > something not a structure or union > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:217: request for member `cwd' in > > something not a structure or union > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:218: request for member `swd' in > > something not a structure or union > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:219: request for member `twd' in > > something not a structure or union > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:220: request for member `fip' in > > > > Any ideas? > > It looks to me like HAVE_PTRACE_GETXFPREGS is getting defined in config.h > when it shouldn't be. I don't think so. # grep HAVE_PTRACE_GETXFPREGS config.h /* #undef HAVE_PTRACE_GETXFPREGS */ > > The following comment may shed some light... > > /* PTRACE_GETXFPREGS is a Cygnus invention, since we wrote our own > Linux kernel patch for SSE support. That patch may or may not > actually make it into the official distribution. If you find that > years have gone by since this code was added, and Linux isn't using > PTRACE_GETXFPREGS, that means that our patch didn't make it, and > you can delete this code. */ > > Do you have PTRACE_GETXFPREGS defined in your system header files > somewhere? > No. -- H.J. Lu (hjl@gnu.org) From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Pierre Muller <muller@cerbere.u-strasbg.fr> Cc: gdb@sourceware.cygnus.com Subject: Re: Updated MAINTAINERS file - work in progress Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A4FB7F.3B87A00F@cygnus.com> References: <200002111033.LAA29442@cerbere.u-strasbg.fr> X-SW-Source: 2000-q1/msg00241.html Content-length: 423 Pierre Muller wrote: > > At 21:33 10/02/00 -0800, you wrote: > >> Andrew Cagney ac131313@cygnus.com? > >> Stan Shebs shebs@cygnus.com? > > Wouldn't it be much more logical to have aliases here ? > > Andrew.Cagney@sourceware.cygnus.com > or even better We could. Unfortunatly it would introduce a dependence on the fsf.org admin and they already have enough to do. Andrew From Stephane.Bihan@arccores.com Sat Apr 01 00:00:00 2000 From: Stephane.Bihan@arccores.com To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <OFFC5FBD39.F51E2E68-ON802568A3.00576DA1@risccores.com> X-SW-Source: 2000-q1/msg00710.html Content-length: 2269 > > Stephane> I also use the breakpoint structure as an extern variable. I > Stephane> needed it to implement the set_hw_breakpoint routine for the > Stephane> remote protocol. I think it's not the nicer way to do but > Stephane> .... > > Can you explain? I don't see any use of struct breakpoint in the > current arc-tdep.c, nor do I see a set_hw_breakpoint function? The version at FSF is a very old version out of date. I am currently extending gdb for ARC to support user extensions. > > >> Since you say you can remove the single step code, I assume that the > >> ISS target and remote protocol agents can perform the single step by > >> themselves? If so, it would be advantageous to disable GDB's single > >> step support. GDB would then issue a single "step" command instead of > >> "insert breakpoint(s)", "continue", and "remove breakpoint(s)". The > >> latency of a step should be greatly improved. > > Stephane> I will implement this for the remote target only since the > Stephane> hardware supports single-stepping. I'm not sure if this > Stephane> feasible in the ISS - Yuri? > > Stephane> If not feasible I won't disable the GDB's single step > Stephane> support (thus enabling a call to single_step()) but I will > Stephane> implement a single_step call to gdbstub in remote_resume(). > > If your ISS target cannot support single step, but the remote protocol > can, perhaps the best thing is to make software single step a target > specific option. By creating a target specific command? The single step mechanism is a not a step-over-calls mechanism. > > I don't think that the arc is the only processor that would benefit > from such a change. For example, the sparclet ROM monitor supports a > single step command, but I do not know if it is ever issued because > the SPARC target uses software single step. Perhaps it inserts the > trap instructions needed for single step and issues the monitor step > command? > > I do not think it's possible for any change to remote_resume() to be > the right solution. > You're right, I've tried and if does not work. Thanks for your explanations anyway. Stephane. ---------------------------------------------------------------- Stephane Bihan ARC Cores Ltd http://www.arccores.com ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <38B5EEDB.8A8F2DD8@cygnus.com>]
* Re: RDI target broken in 000215 snapshot [not found] ` <38B5EEDB.8A8F2DD8@cygnus.com> @ 2000-04-01 0:00 ` Grant Edwards 0 siblings, 0 replies; 6+ messages in thread From: Grant Edwards @ 2000-04-01 0:00 UTC (permalink / raw) To: Andrew Cagney; +Cc: Fernando Nasser, Fernando Nasser, gdb > o as soon as GDB encounters a binary > it pokes around the bfd file to determine > the endianess and uses that (provided things > are still auto). That implies that when I loaded a big-endian file it should have switched to big-endian. It didn't seem to -- I'll have to try that again. > To the best of my knowledge, no one has seriously investigated how to > set up an interface where the target determines architectural > information (such as endianess). Since 50% of my sample of 2 target interfaces don't correctly report endianess, it may not be something worth investigating. > it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the > wrong place. Now that I know what happened, it's not a big deal. I can just set it in .gdbinit. -- Grant Edwards grante@visi.com From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs <shebs@apple.com> To: "Frank Ch. Eigler" <fche@cygnus.com> Cc: gdb@sourceware.cygnus.com, Stephane.Bihan@arccores.com Subject: Re: how to integrate an ISS target in the gdb tree Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D6C365.F2942D51@apple.com> References: <OF44E75EE3.DD68FAE0-ON802568A8.0056F26A@risccores.com> <o5d7opqr6x.fsf@toenail.to.cygnus.com> X-SW-Source: 2000-q1/msg00748.html Content-length: 458 "Frank Ch. Eigler" wrote: > I believe we will need an FSF copyright assignment, so you may want to get > started on that paperwork in parallel. Historically, not all simulators have been assigned to the FSF. But while one could make an argument that the sims are separate somehow, it doesn't set a very good precedent - the whole point of the assignment policy is to have consistent ownership, rather than the patchwork that's currently under sim/. Stan From alexey@vocord.com Sat Apr 01 00:00:00 2000 From: Alexey <alexey@vocord.com> To: gdb@sourceware.cygnus.com Subject: Need help with remote debug! Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BAA89B.93B653B4@vocord.com> X-SW-Source: 2000-q1/msg00438.html Content-length: 315 Hello! I want to use gdb to remote debug applications on my board with mips p4650 through the shared memory. I put printk in ioctl in driver. So I can see what gde send somthing with cmd 0x5401 and 0x5402 - TCGETS and TCSETS So the question is: what does gdb send and what he is want to recieve? Regards Alexey ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RDI target broken in 000215 snapshot [not found] ` <38B2AD14.7B0B4A4E@redhat.com> 2000-02-24 10:47 ` RDI target broken in 000215 snapshot Grant Edwards @ 2000-04-01 0:00 ` Grant Edwards 1 sibling, 0 replies; 6+ messages in thread From: Grant Edwards @ 2000-04-01 0:00 UTC (permalink / raw) To: Fernando Nasser; +Cc: gdb On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote: > > The RDI target support seems to be broken in the 000215 > > snapshot. I'm unable to execute any of the eCos test programs, > > or any other applictions I've written. (they run fine with a > > patched-up 4.18 gdb). I don't know what's wrong with it and > > won't have time to look at it for a while. > > Can you be more specific? It is working right with the AEB board and > with another one I have here. Both use serial ports. I tried it using the ARM Embedded ICE with serial-only and with serial-parallel interfaces. It connects to the device OK, and I can load a file and set breakpoints, but when I type "cont", gdb just hangs. Ctrl-C doesn't get any response, and I have to suspend and then kill gdb. (This usually means that gdb is waiting for a response from the JTAG interface box, and it isn't sending anything.) The exact same sequence of operations w/ patched 4.18 works (the program runs properly, hits the expected breakpoint, etc.). I haven't tried it with the EPI Jeeni. I plan on comparing ADP packet logs to see what is different, but this week is pretty busy and next week I'm going to be at the Embedded Systems Conference in Chicago. So I won't get a chance to play with it for a couple weeks. > Please let me know what is your host machine, what version of > tools did you use to build gdb, if on cygwin, which version of > the dll and, last but not least, what is it that you are > getting on the console. Host: Linux-Intel (Vanilla RH6.1 w/ 2.2.12-20 kernel) Gcc: egcs-2.91.66 (came w/ RH6.1) > > Is somebody currently working on the RDI code? If so, I'll > > leave well enough alone until the code stabilizes. > > > The usual folks. You, myself, Thomas, Nick, Jim... and I build and > test it at least twice a week. Odd. The ADP protocol/code from ARM is pretty fragile. If the target doesn't reply to a command, the whole thing sits there and you have to kill gdb, reset the target, and start over. Onee could add a receive timeout, but it won't do any good if the JTAG interface box is hung. There's also the problem of the two ends of the ADP connection getting frame sequence numbers out of sync -- so there may not be a practical solution other that the current "reset both ends and start over" approach. -- Grant Edwards grante@visi.com From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon <kingdon@redhat.com> To: gdb@sourceware.cygnus.com Subject: Re: So who maintains the web pages? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <bsnyxc2iy.fsf@rtl.cygnus.com> References: <38A60492.2BB9E437@cygnus.com> <bu2jdc2mp.fsf@rtl.cygnus.com> X-SW-Source: 2000-q1/msg00252.html Content-length: 277 > As for what to put in MAINTAINERS, how about "anyone listed in this > file (in any section) may have write-without-approval . . . Oh, and if you want someone to be the "lead maintainer" or "lead victim" or some such concept for the web pages, feel free to put me down. From taylor@cygnus.com Sat Apr 01 00:00:00 2000 From: David Taylor <taylor@cygnus.com> To: Pierre Muller <muller@cerbere.u-strasbg.fr> Cc: gdb@sourceware.cygnus.com Subject: Re: Status of submitted patches? Pascal language addition patch. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002011920.OAA02797@texas.cygnus.com> X-SW-Source: 2000-q1/msg00087.html Content-length: 671 From: Pierre Muller <muller@cerbere.u-strasbg.fr> Date: Tue, 01 Feb 2000 18:02:13 +0100 I submitted a big patch for adding Pascal Language support in GDB already 1999/10/22. I'm afraid that I don't remember much about the patch; nor do I have a copy of it stashed away. Small patches are better than big patches. The larger the patch the longer it takes to read and evaluate -- and it is definitely non linear. Up to a point it seems to be roughly quadratic -- double the size of the patch and it takes maybe four times longer to understand it. Please resubmit the patch (against a recent snapshot) and we'll try to do better this time around. From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis <kettenis@wins.uva.nl> To: blizzard@mozilla.org Cc: gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002121759.e1CHxMG02867@delius.kettenis.local> References: <38A47E89.3F4674B3@mozilla.org> X-SW-Source: 2000-q1/msg00244.html Content-length: 5673 Date: Fri, 11 Feb 2000 16:26:33 -0500 From: Chris Blizzard <blizzard@mozilla.org> Hi, folks. I've been talking about some problems that I've been suffering through with gdb and mozilla which people on this mailing list may or may not be aware of. Jason Molenda suggested that I start flushing these out in the open to get some feedback on them. I'm interested in getting my hands dirty and try to get these problems fixed. I'm not a debugger hacker though so I might end up asking some silly questions. :) No problem! May I ask some questions first? What version of GDB are you using? What version of GCC are you using? Here's the blurb, slightly edited for content. ...My problems are mostly related to how well gdb scales to handle large shared libraries and large numbers of shared libraries. At last count, there were 111 .so files in mozilla, the largest of which is about 27 meg with debugging symbols. If you don't use "set auto-solib-add 0" in your .gdbinit file, gdb will easily grow to over 200 meg in size when starting the debugger. Someone once did some estimates and it seems to use 5 times the size of a .so after loading a shared library to debug. A lot of times, gdb won't be able to load some of the larger .so files. It just hangs. Let me first say that Mozilla seems to stretch things to the limit. The huge number of shared libraries that you guys are using have already uncovered several bugs in the dynamic linker and the Mozilla developers have uncovered more than a few bugs in the LinuxThreads library. That's mostly because you have gone where no one's gone before :-) From a quick glance at the output of `ps' on my system when loading a program that uses about 10 shared libraries it seems that the GDB memory usage is aproximately equal to the size of the shraed libraries on disk. I guess the "factor 5" estimate, is referring to the space used for debugging symbols as compared to the actual code-size of the shared library. So it seems that your biggest problem is the size of your shared libraries and the amount of debugging information that's generated (which is basically proportional to the amount of code in the libraries). I think that using C++ is in a large way responsible for the `code bloat'. Maybe an intelligent use of C++ features (check for compiler switches like -fno-rtti and use them if appropriate) can reduce the size of the resulting code. Also playing around with the options that control the way debugging information is generated might help. In principle the large amounts of debugging info shouldn't be a problem. GDB can simply mmap the relevant sections, such that only the debugging info that's really needed is actually pages in. I don't know how the BFD library (the part of GDB that is responsible for reading the sections containing debugging info) and the code that that actually interprets this information implements these things. There might be room for improvement there. Of course if all pages containing debugging info are touched, you lose :-(. A lot of times, trying to use "step" to step into a c++ method that happens to be part of the same class just skips as if you had used "next." That means that any time you want to step into a method you have to set a temporary breakpoint by name on the method and then allow the breakpoint to get you into that method. Doing that to step into a dozen or so classes gets a little tedious. This is hard to reproduce and I'm trying to build a test case. It is a known problem that GDB has problems with the debugging output generated by recent GCC compilers. Help in resolving those problems would certainly be appreciated, and a (small) test case is really essential if you want to get somebody else to look into it. Compiling without optimization might circumvent these problems. There are other much needed features, like not being able to preload a .so and setting a breakpoint in the library before it loads. Mozilla is entirely component based and this makes debugging very, very difficult. I usually break on _dl_open in glibc and wait until my library gets loaded before trying to set the breakpoint that I need. That gets pretty bad after 27 libraries are loaded. I think that the way GDB looks up symbols is differs from the way the dynamic linker does that. That means that overriding symbols in shared libraries probably doesn't work properly. Since the primary use of preloaded shared libraries is overriding symbols you're likely to experience problems. I don't think this problem is easy to solve. Setting breakpoints in not-yet loaded shared libraries should not be difficult to implement. Just make sure they start out as `shlib_disabled' (see breakpoint.h) if the symbol cannot be found. It is necessary to introduce a new command to do this (suggested name `shlib-break' or `solib-break'). Reusing the guts of the ordinary breakpoint setting command should be possible. There are also various problems with threads. A lot of times gdb won't exit after the last thread exits because it keeps trying to kill a process which doesn't exist any more. Probably caused by the strange way threads interact with signals on Linux. It's very likely that the real bug is in the LinuxThreads library and not in GDB. A lot of LinuxThreads problems have recently been solved. You might want to try the latest glibc 2.1.3 pre-release. Or have a little patience, glibc 2.1.3 is supposed to be released real soon now. Hope this helps, and I'm looking forward to your contributions :-), Mark From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Jonathan Larmour <jlarmour@redhat.co.uk> Cc: gdb@sourceware.cygnus.com Subject: Re: copyright banner and reporting bugs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DF418A.42355DAD@cygnus.com> References: <38CFF922.6BA6928E@redhat.co.uk> X-SW-Source: 2000-q1/msg00817.html Content-length: 547 Jonathan Larmour wrote: > > I just noticed two minor things: surely the copyright banner when GDB starts > should be something more recent than 1998 even now - i.e. it shouldn't need > to wait for the release. Good point. It should pick up Makefile.in:VERSION. > Also on http://sourceware.cygnus.com/gdb it isn't at all clear how users > report bugs. This is worthy of a section in its own right surely! Just an > appropriate regurgitation of the info file node from gdb.texinfo would be > enough. I've updated it. Feedback welcome. Andrew From velco@fadata.bg Sat Apr 01 00:00:00 2000 From: Momchil Velikov <velco@fadata.bg> To: GDB List <gdb@sourceware.cygnus.com> Subject: Remote debugging over UDP Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DFABC7.A884D5D7@fadata.bg> X-SW-Source: 2000-q1/msg00825.html Content-length: 362 Hi, I have added support for debugging remote targets over UDP ("added support", that's cloned ser-tcp.c and tweaked it a little bit). Are interested in including that in GDB ? Do you mind changing the syntax the parameter NAME to serial.c:serial_open () to tcp:<host>:<port>, and udp:<host>:<port> for TCP and UDP connections, respectively ? Regards, -velco From toddpw@windriver.com Sat Apr 01 00:00:00 2000 From: Todd Whitesel <toddpw@windriver.com> To: kingdon@redhat.com (Jim Kingdon) Cc: akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Regression caused by elfread.c patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002150800.AAA07477@alabama.wrs.com> References: <200002150453.XAA11268@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00289.html Content-length: 1928 > I don't see how your patch could work at all - sym->section->index is > a very different number than a SECT_OFF_* code. The SECT_OFF_* code In case it interests anyone, I spent most of January figuring out how to teach GDB how to let both cases coexist properly. It is my considered opinion that the SECT_OFF_* machinery really only works when all the offsets are the same. However, so few configurations (read: vxWorks and ??) actually use different offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the problems with it. (We read relocatable .o files too, which is also rare.) Our particular bug is as follows: for a.out, read-only data gets put into .text, but the stabs generated are indistinguishable (or prohibitively hard to distinguish, anyway) from a non-const version of the same item which gets put into .data. Thus it is impossible to find the correct address without using actual relocation records. (The same bug occurs on ELF although in this case it is because .rodata is classed as a text section by our loader, which then feeds us a single address for the group of text sections. sigh) One of our consultants developed code for ELF/DWARF relocatables which actually calls bfd_final_link_relocate to process reloc info, because in the DWARF case we have even less information to tell things apart than with stabs. I extended that to do full final address relocation and worked out how to have struct section_offsets keep track of what is going on, so that ANOFFSET can be replaced with a variety of different macros depending on what usage is intended. (This also allowed optional asserts to be compiled in, which turned out to be helpful once I started testing, and illuminated a few cases too.) A gutted tarball of 4.17+local sources is temporarily available (in an execute-only directory) at: ftp://ftp.toddpw.org/private/vxgdb.tar.bz2 -- Todd Whitesel toddpw @ windriver.com From davea@dsl-quasar.corp.sgi.com Sat Apr 01 00:00:00 2000 From: davea@dsl-quasar.corp.sgi.com (David B. Anderson) To: gdb@sourceware.cygnus.com Subject: Re: mdebug Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003312258.OAA25181@dsl-quasar.corp.sgi.com> X-SW-Source: 2000-q1/msg00847.html Content-length: 1092 Elena Zannoni <ezannoni@cygnus.com> writes: >Does anybody know something about mdebug? Yes. >I am trying to figure out a problem in gdb which untilmately is due >to some limitation of mdebug. >Is there any documentation at all about how the debug symbols are built? http://reality.sgi.com/davea/objectinfo.html Look early in the page for: one part of the old 32bit ABI for MIPS is the mdebug debugging information. A postscript file with the only currently available description of this data is here (119Kbytes) It is is an old paper I wrote on mdebug. Not too well written, but... what else is there? Perhaps it will help. Does not mention limits, though. The limits are implicit in various structs. Perhaps 'explicit' is a better word :-) If you have any questions let me know. (whether I'll know the answer is something else...) I don't know too much about DEC or other *extensions* to mdebug. Just sgi's. But there are certainly some important limitations in mdebug. Like 64K procedures (at most). SGI did some hack extensions, but ... never mind. davea@sgi.com From srikanth@cup.hp.com Sat Apr 01 00:00:00 2000 From: Srikanth <srikanth@cup.hp.com> To: Chris Blizzard <blizzard@redhat.com> Cc: gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AB3457.6902@cup.hp.com> References: <38A47E89.3F4674B3@mozilla.org> <npael3tqk6.fsf@zwingli.cygnus.com> <38AB2DC4.FA9A3C71@redhat.com> X-SW-Source: 2000-q1/msg00315.html Content-length: 4577 Chris Blizzard wrote: > > So, one of the problems that I've been having is that some large .so libraries > take forever to load. One of the libraries is about 28 meg with debugging > symbols in it. I've let it run for about 10 mins and it's never finished > loading. Here's what gprof says for loading a reasonable sized library ( 5 > meg or so ): > > Flat profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 70.98 19.47 19.47 11954 1.63 2.25 lookup_minimal_symbol > 27.12 26.91 7.44 33240213 0.00 0.00 strcmp_iw > 0.33 27.00 0.09 3 30.00 9038.95 read_dbx_symtab > 0.15 27.04 0.04 44554 0.00 0.00 hash > 0.11 27.07 0.03 337915 0.00 0.00 bfd_getl32 > 0.11 27.10 0.03 44554 0.00 0.00 bcache > 0.11 27.13 0.03 150 0.20 0.20 end_psymtab > > Uhh...that's 33 _million_ calls. That looks like this chunk of code: > > for (objfile = object_files; > objfile != NULL && found_symbol == NULL; > objfile = objfile->next) > { > if (objf == NULL || objf == objfile) > { > for (msymbol = objfile->msymbols; > msymbol != NULL && SYMBOL_NAME (msymbol) != NULL && > found_symbol == NULL; > msymbol++) > { > if (SYMBOL_MATCHES_NAME (msymbol, name)) > { > switch (MSYMBOL_TYPE (msymbol)) > { > case mst_file_text: > > I'm sorry, is that looking over a linked list? SYMBOL_MATCHES_NAME() is a > macro that does some mangling magic so we can't use a standard hash lookup > table but there has to be something we can do to speed that up. > > --Chris > We at HP have been running into many of these issues and have substantially re-architected the symbol table management to achieve performance. Here are some of the things we did : (1) The function lookup_minimal_symbol believe it or not performs linear search. The minimal symbol table is sorted by the symbol address and not by name, so binary searches are possible in lookup_minimal_symbol_by_pc but not in lookup_minimal_symbol () The difficulty here is that a name lookup could be based on either a demangled name or a mangled name. So unless we sort the table by both we will have to do linear search. Sorting the table by both involves heavy penalty at startup, as that entail three sorts with different keys (PC, demangled name and mangled name). We eliminated one of the keys : the demangled name and do a double sort. (2) Just in time demangling : Rightnow, gdb demangles the linker symbol table at startup. This simply does not scale well to large applications. We implemented a scheme by which we eliminate all anticipatory demangling and do it just in time, only for the set of symbols the user refers to in a debugging session. Other than the "minimal" symbol table, there could be other spots where whole scale anticipatory demangling could be going on : in build_psymtabs() etc ... Avoiding anticipatory demangling allowed us to eliminate one of the sort keys for (1) above. This may or may not be possible to do with your compiler. (3) GDB internalizes the native debugging information in its entirety. Studies show a "typical" debugging session uses less than 15% all debug info from a binary. (4) For C++, it is very likely the linker (minimal) symbol table contains all kinds of compiler generated symbols for such things like vtables, exception handling, RTTI etc. Also based on your compiler, last of internal symbols generated for the purpose of relocation could be making their way into the linker symbol table. Do a maint print msymbols <filename> and take a look for symbols that don't look like user space symbols. Some of these symbols are crucial for gdb ro interact properly with the runtime. But there could be others.... (5) The bcache could be extremely expensive in some platforms. What this module does is to try to eliminate duplicates in debug info. Some platforms (like HP) eliminate all (most) redundancy in the debug info in a hidden linker pass. For HP we simply disconnected the bcache and saw a 50% improvement in memory and 20% or so performance improvement. (6) Compilers could be emitting too much debug info than is necessary. Some compilers try to be optimal but some don't. Hope this is helpful. Srikanth From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: Michael Snyder <msnyder@cygnus.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: dan@cgsoftware.com, Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com, drepper@cygnus.com Subject: Re: lin-thread cannot handle thread exit Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CEE0DD.11A@cygnus.com> References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <u2ihhvav.fsf@dan.resnet.rochester.edu> <38C7EDFB.7457@cygnus.com> <38CDEDC5.4107034@cygnus.com> <38CE81B2.9CA@cygnus.com> <38CEDB3E.DA17FA9A@cygnus.com> X-SW-Source: 2000-q1/msg00705.html Content-length: 472 Andrew Cagney wrote: > > Michael Snyder wrote: > > > As far as I can tell, yes it did. > > This is something that the thread_db implementation was > > designed to handle -- I just didn't get around to it. > > I hope to be able to fit it in "real soon now". > > So this effectivly means that this particular thread problem is a ``nice > to have'' rather than a ``must have'' for 5.0. > > Something that can be better easier fixed in the 5.1 timeframe. I would say so. From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: Re: memory region attribute CLI Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5m3dplwjri.fsf@jtc.redbacknetworks.com> References: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> <200003160944.EAA01842@indy.delorie.com> <5mem9avs45.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00745.html Content-length: 11575 >>>>> "jtc" == J T Conklin <jtc@redback.com> writes: jtc> Yes, I guess it has been a while, hasn't it. jtc> jtc> Start at: jtc> http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00168.html No comments? Here's a bit more meat. I've gone ahead and implemented the CLI, and would appreciate any comments. I'm planning on writing documentation and making the changes to use these attributes this week. Many thanks, --jtc /* memattr.h */ #ifndef MEMATTR_H #define MEMATTR_H /* FIXME: I stole this bit from tracepoint.h. The definition should probably be moved out of breakpoint.h, tracepoint.h, and memattr.h and into defs.h or something like that. */ #if !defined (BREAKPOINT_H) enum enable { disabled, enabled }; #endif enum mem_access_mode { MEM_RW, /* read/write */ MEM_RO, /* read only */ MEM_WO, /* write only */ }; enum mem_access_width { MEM_WIDTH_UNSPECIFIED, MEM_WIDTH_8, /* 8 bit accesses */ MEM_WIDTH_16, /* 16 " " */ MEM_WIDTH_32, /* 32 " " */ MEM_WIDTH_64 /* 64 " " */ }; /* The set of all attributes that can be set for a memory region. This structure was created so that memory attributes can be passed to target_ functions without exposing the details of memory region list, which would be necessary if these fields were simply added to the mem_region structure. FIXME: It would be useful if there was a mechanism for targets to add their own attributes. For example, the number of wait states. */ struct mem_attrib { /* read/write, read-only, or write-only */ enum mem_access_mode mode; enum mem_access_width width; /* enables hardware breakpoints */ int hwbreak; /* enables host-side caching of memory region data */ int cache; /* enables memory verification. after a write, memory is re-read to verify that the write was successful. */ int verify; }; struct mem_region { /* FIXME: memory regions are stored in an unsorted singly-linked list. This probably won't scale to handle hundreds of memory regions --- that many could be needed to describe the allowed access modes for memory mapped i/o device registers. */ struct mem_region *next; CORE_ADDR lo; CORE_ADDR hi; /* Item number of this memory region. */ int number; /* Status of this memory region (enabled or disabled) */ int status; /* Attributes for this region */ struct mem_attrib attrib; }; extern struct mem_region *lookup_mem_region(CORE_ADDR); #endif /* MEMATTR_H */ /* memattr.c */ #include "defs.h" #include "command.h" #include "gdbcmd.h" #include "memattr.h" #include "gdb_string.h" const struct mem_attrib default_mem_attrib = { MEM_RW, /* mode */ MEM_WIDTH_UNSPECIFIED, false, /* hwbreak */ false, /* cache */ false /* verify */ }; static struct mem_region *mem_region_chain = NULL; static mem_number = 0; static struct mem_region * create_mem_region (CORE_ADDR lo, CORE_ADDR hi, const struct mem_attrib *attrib) { struct mem_region *n, *p, *new; if (lo > hi) { printf_unfiltered ("invalid memory region\n"); return NULL; } n = mem_region_chain; while (n) { /* overlapping node */ if ((lo >= n->lo && lo <= n->hi) || (hi >= n->lo && hi <= n->hi)) { printf_unfiltered ("overlapping memory region\n"); return NULL; } } new = xmalloc (sizeof (struct mem_region)); new->lo = lo; new->hi = hi; new->number = ++mem_number; new->status = enabled; new->attrib = *attrib; /* link in new node */ new->next = mem_region_chain; mem_region_chain = new; return new; } static void delete_mem_region(struct mem_region *m) { free(m); } struct mem_region * lookup_mem_region(CORE_ADDR addr) { struct mem_region *m; for (m = mem_region_chain; m; m = m->next) { if (addr >= m->lo && addr <= m->hi) return m; } return NULL; } \f static void mem_command (char *args, int from_tty) { CORE_ADDR lo, hi; char *tok; struct mem_attrib attrib; if (!args) error_no_arg("No mem"); tok = strtok(args, " \t"); if (!tok) error("no lo address"); lo = parse_and_eval_address(tok); tok = strtok(NULL, " \t"); if (!tok) error("no hi address"); hi = parse_and_eval_address(tok); attrib = default_mem_attrib; while ((tok = strtok (NULL, " \t")) != NULL) { if (strcmp (tok, "rw") == 0) attrib.mode = MEM_RW; else if (strcmp (tok, "ro") == 0) attrib.mode = MEM_RO; else if (strcmp (tok, "wo") == 0) attrib.mode = MEM_WO; else if (strcmp (tok, "8") == 0) attrib.width = MEM_WIDTH_8; else if (strcmp (tok, "16") == 0) { if ((lo % 2 != 0) || (hi % 2 != 0)) error ("region bounds not 16 bit aligned"); attrib.width = MEM_WIDTH_16; } else if (strcmp (tok, "32") == 0) { if ((lo % 4 != 0) || (hi % 4 != 0)) error ("region bounds not 32 bit aligned"); attrib.width = MEM_WIDTH_32; } else if (strcmp (tok, "64") == 0) { if ((lo % 8 != 0) || (hi % 8 != 0)) error ("region bounds not 64 bit aligned"); attrib.width = MEM_WIDTH_64; } else if (strcmp (tok, "hwbreak") == 0) attrib.hwbreak = true; else if (strcmp (tok, "swbreak") == 0) attrib.hwbreak = false; else if (strcmp (tok, "cache") == 0) attrib.cache = true; else if (strcmp (tok, "nocache") == 0) attrib.cache = false; else if (strcmp (tok, "verify") == 0) attrib.verify = true; else if (strcmp (tok, "noverify") == 0) attrib.verify = false; else error ("unknown attribute: %s", tok); } create_mem_region(lo, hi, &attrib); } \f static void mem_info_command (char *args, int from_tty) { struct mem_region *m; struct mem_attrib *attrib; if (!mem_region_chain) { printf_unfiltered ("There are no memory regions defined.\n"); return; } printf_filtered ("Memory regions now in effect:\n"); for (m = mem_region_chain; m; m = m->next) { printf_filtered ("%d: %c\t", m->number, m->status ? 'y' : 'n'); printf_filtered ("%s - ", local_hex_string_custom ((unsigned long) m->lo, "08l")); printf_filtered ("%s\t", local_hex_string_custom ((unsigned long) m->hi, "08l")); /* Print a token for each attribute. * * FIXME: Should we output a comma after each token? It may * make it easier for users to read, but we'd lose the ability * to cut-and-paste the list of attributes when defining a new * region. Perhaps that is not important. * * FIXME: If more attributes are added to GDB, the output may * become cluttered and difficult for users to read. At that * time, we may want to consider printing tokens only if they * are different from the default attribute. */ attrib = &m->attrib; switch (attrib->mode) { case MEM_RW: printf_filtered ("rw "); break; case MEM_RO: printf_filtered ("ro "); break; case MEM_WO: printf_filtered ("wo "); break; } switch (attrib->width) { case MEM_WIDTH_8: printf_filtered ("8 "); break; case MEM_WIDTH_16: printf_filtered ("16 "); break; case MEM_WIDTH_32: printf_filtered ("32 "); break; case MEM_WIDTH_64: printf_filtered ("64 "); break; case MEM_WIDTH_UNSPECIFIED: break; } if (attrib->hwbreak) printf_filtered ("hwbreak"); else printf_filtered ("swbreak"); if (attrib->cache) printf_filtered ("cache "); else printf_filtered ("nocache "); if (attrib->verify) printf_filtered ("verify "); else printf_filtered ("noverify "); printf_filtered ("\n"); gdb_flush (gdb_stdout); } } \f /* Enable the memory region number NUM. */ static void mem_enable (int num) { struct mem_region *m; for (m = mem_region_chain; m; m = m->next) if (m->number == num) { m->status = enabled; return; } printf_unfiltered ("No memory region number %d.\n", num); } static void mem_enable_command (char *args, int from_tty) { char *p = args; char *p1; int num; struct mem_region *m; if (p == 0) { for (m = mem_region_chain; m; m = m->next) m->status = enabled; } else while (*p) { p1 = p; while (*p1 >= '0' && *p1 <= '9') p1++; if (*p1 && *p1 != ' ' && *p1 != '\t') error ("Arguments must be memory region numbers."); num = atoi (p); mem_enable (num); p = p1; while (*p == ' ' || *p == '\t') p++; } } \f /* Disable the memory region number NUM. */ static void mem_disable (int num) { struct mem_region *m; for (m = mem_region_chain; m; m = m->next) if (m->number == num) { m->status = disabled; return; } printf_unfiltered ("No memory region number %d.\n", num); } static void mem_disable_command (char *args, int from_tty) { char *p = args; char *p1; int num; struct mem_region *m; if (p == 0) { for (m = mem_region_chain; m; m = m->next) m->status = disabled; } else while (*p) { p1 = p; while (*p1 >= '0' && *p1 <= '9') p1++; if (*p1 && *p1 != ' ' && *p1 != '\t') error ("Arguments must be memory region numbers."); num = atoi (p); mem_disable (num); p = p1; while (*p == ' ' || *p == '\t') p++; } } /* Clear memory region list */ static void mem_clear (void) { struct mem_region *m; while ((m = mem_region_chain) != 0) { mem_region_chain = m->next; delete_mem_region(m); } } /* Delete the memory region number NUM. */ static void mem_delete(int num) { struct mem_region *m1, *m; if (!mem_region_chain) printf_unfiltered ("No memory region number %d.\n", num); if (mem_region_chain->number == num) { m1 = mem_region_chain; mem_region_chain = m1->next; delete_mem_region(m1); } else for (m = mem_region_chain; m->next; m = m->next) { if (m->next->number == num) { m1 = m->next; m->next = m1->next; delete_mem_region(m1); break; } } printf_unfiltered ("No memory region number %d.\n", num); } static void mem_delete_command (char *args, int from_tty) { char *p = args; char *p1; int num; if (p == 0) { if (query ("Delete all memory regions? ")) mem_clear(); dont_repeat(); return; } while (*p) { p1 = p; while (*p1 >= '0' && *p1 <= '9') p1++; if (*p1 && *p1 != ' ' && *p1 != '\t') error ("Arguments must be memory region numbers."); num = atoi (p); mem_delete (num); p = p1; while (*p == ' ' || *p == '\t') p++; } dont_repeat(); } _initialize_mem () { add_com ("mem", class_vars, mem_command, "Define attributes for memory region."); add_cmd ("mem", class_vars, mem_enable_command, "Enable memory region.\n\ Arguments are the code numbers of the memory regions to enable.\n\ Do \"info mem\" to see current list of code numbers.", &enablelist); add_cmd ("mem", class_vars, mem_disable_command, "Disable memory region.\n\ Arguments are the code numbers of the memory regions to disable.\n\ Do \"info mem\" to see current list of code numbers.", &disablelist); add_cmd ("mem", class_vars, mem_delete_command, "Delete memory region.\n\ Arguments are the code numbers of the memory regions to delete.\n\ Do \"info mem\" to see current list of code numbers.", &deletelist); add_info ("mem", mem_info_command, "Memory region attributes"); } -- J.T. Conklin RedBack Networks From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Robert Lipe <robertl@sco.com> Cc: gdb@sourceware.cygnus.com Subject: Re: config.guess version regression Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B31515.73EA86EB@cygnus.com> References: <20000222151535.A23483@rjlhome.sco.com> X-SW-Source: 2000-q1/msg00374.html Content-length: 1060 Robert Lipe wrote: > > I suspect this is a result of the repository shuffling in recent weeks, > but the top-level config.guess went back several versions. This means > that some later OSes (i586-sco-sysv5uw7.1.1 in my case) is no longer > automatically recognized. FYI, getting config.guess updated is on my 5.0 hit list. > Should I submit an explicit patch to resync it against the one in > autoconf or can someone with CVS accesses to both just plunk a new > version in? If this is considered too radical, I suppose we can fish > for the config.guess that lived in gdb before the big restructuring. I'ts not at all radical :-) I've already done a heads up on the binutils side. I've just got to push the keys :-) Franz Sirl wrote: > Please don't sync with autoconf, it's currently outdated. Either sync with the > master repository "cvs -d :pserver:anoncvs@subversions.gnu.org:/home/cvs > co config" or use the one in GCC, which I synced last week. Ah, and don't > forget to sync both config.guess and config.sub. thanks for this pointer Andrew From dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: Daniel Berlin <dan@cgsoftware.com> To: gdb@sourceware.cygnus.com Subject: RTTI working for G++ Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <Pine.LNX.4.10.10003131601500.8750-100000@localhost.localdomain> X-SW-Source: 2000-q1/msg00692.html Content-length: 3476 Okay, i have RTTI working for g++. Well, all except for multiple inheritance. Scratch that last part, i just made it offset properly if you have >1 baseclass, so al is good. If i could have one or two volunteers to make sure it's not just my setup, and that all is well, before i post the patches asking for comments, i'd appreciate it. In any case, let me know what you guys think of it so far. If you look at the output, you'll notice that while for printing, it will print the object as if it was it's derived type, when it comes to accessing members/methods, just like in C++, you can't access the members, unless you specifically cast it to that derived type. For those wondering what the patch will do, check this out: The inheritance on these classes in the example looks like this fred is a base dan and bob both inherit directly from fred. george is another base. george2 inherits from george and bob (public george, public bob) I'll rename them so they make more sense as i work up testcases. But anyway, here's some output: GNU gdb 20000204 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsdelf4.0". Setting up the environment for debugging gdb. .gdbinit:5: Error in sourced command file: No symbol table is loaded. Use the "file" command. (gdb) file a.out Reading symbols from a.out...done. (gdb) b main Breakpoint 1 at 0x8048918: file a.cc, line 29. (gdb) set print object on (gdb) set print pretty on (gdb) set print vtbl on (gdb) set print array on (gdb) r Starting program: /usr/local/gdb/src/gdb/a.out Breakpoint 1, 0x8048918 in main () at a.cc:29 29 { (gdb) n 31 dan=new daniel(); (gdb) n 32 cout <<typeid(*dan).name()<<endl; (gdb) p dan $1 = (daniel *) 0x8051030 (gdb) p dan[0] $2 = (daniel) { <fred> = { a = 0, _vptr$ = 0x804f390 }, members of daniel: b = 0 } (gdb) ptype dan type = class fred { public: int a; fred & operator=(fred const &); fred(fred const &); fred(void); virtual int ab(void); } * (gdb) p dan[0]->b There is no member or method named b. (gdb) n 6daniel 33 dan=new bob(); (gdb) 34 dan=new george2(); (gdb) p dan $3 = (bob *) 0x8051040 (gdb) p dan[0] $4 = (bob) { <fred> = { a = 0, _vptr$ = 0x804f378 }, members of bob: c = 0 } (gdb) p dan[0].c There is no member or method named c. (gdb) n 35 dan->a=55; (gdb) p dan[0] $5 = (george2 [incomplete object]) { <george> = { d = 0 }, <bob> = { <fred> = { a = 0, _vptr$ = 0x804f360 }, members of bob: c = 0 }, members of george2: e = 0 } (gdb) l 30 fred *dan; 31 dan=new daniel(); 32 cout <<typeid(*dan).name()<<endl; 33 dan=new bob(); 34 dan=new george2(); 35 dan->a=55; 36 cout <<typeid(*dan).name()<<endl; 37 } 38 (gdb) n 36 cout <<typeid(*dan).name()<<endl; (gdb) p dan $7 = (suspicious *) 0x8050064 (gdb) p dan[0] $8 = (george2 [incomplete object]) { <george> = { d = 0 }, <bob> = { <fred> = { a = 55, _vptr$ = 0x804f360 }, members of bob: c = 0 }, members of george2: e = 0 } (gdb) c Continuing. 7george2 Program exited normally. (gdb) q Script done on Mon Mar 13 19:34:51 2000 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20000221104541.A28578@visi.com>
[not found] ` <38B2AD14.7B0B4A4E@redhat.com>
2000-02-24 10:47 ` RDI target broken in 000215 snapshot Grant Edwards
2000-04-01 0:00 ` Fernando Nasser
[not found] ` <20000224134607.A6354@visi.com>
2000-02-24 12:01 ` Fernando Nasser
[not found] ` <38B59CE1.4CFA7F1E@cygnus.com>
[not found] ` <20000224152638.A2092@visi.com>
[not found] ` <38B61CF6.B4F80802@cygnus.com>
[not found] ` <38B69A2A.ED2DC6F3@redhat.com>
2000-04-01 0:00 ` Grant Edwards
[not found] ` <38B5EEDB.8A8F2DD8@cygnus.com>
2000-04-01 0:00 ` Grant Edwards
2000-04-01 0:00 ` Grant Edwards
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox