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 To: Fernando Nasser Cc: Fernando Nasser , 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 To: Grant Edwards Cc: Fernando Nasser , 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 To: Fernando Nasser Cc: Fernando Nasser , 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 To: Grant Edwards Cc: Fernando Nasser , 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 To: Fernando Nasser Cc: Fernando Nasser , 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 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 To: "William A.Gatliff" 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 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 To: Hany Morcos , 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 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 To: Fernando Nasser Cc: Grant Edwards , Fernando Nasser , 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 To: Mark Kettenis 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 > > 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 To: Andrew Cagney Cc: Fernando Nasser , Fernando Nasser , 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 To: Grant Edwards Cc: Fernando Nasser , 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 To: Andrew Cagney Cc: Grant Edwards , Fernando Nasser , 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 To: Fernando Nasser Cc: Andrew Cagney , Fernando Nasser , 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 To: Grant Edwards Cc: Andrew Cagney , Fernando Nasser , 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 To: "fnasser@cygnus.com" Cc: James Ingham , GDB Mailing List 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 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 To: Scott Bambrough Cc: GDB Mailing List 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> 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 To: gdb@sourceware.cygnus.com Subject: Re: command error handling Date: Sat, 26 Feb 2000 10:30:00 -0000 Message-id: 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 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