From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Jim Blandy , elena@cygnus.com Cc: James Wilson , gdb-patches@sourceware.cygnus.com Subject: Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) Date: Mon, 19 Jun 2000 19:03:00 -0000 Message-id: <394ED0B7.EFE765A8@cygnus.com> References: <200006200106.SAA22809@wilson.cygnus.com> X-SW-Source: 2000-06/msg00238.html [to/cc re-aranged] James Wilson wrote: > 2000-06-19 James E. Wilson > * gdbtypes.h (struct type): Change type of length and bitpos fields to > long. Um, again, shouldn't this be LONGEST? Andrew >From wilson@wilson.cygnus.com Mon Jun 19 19:13:00 2000 From: James Wilson To: Andrew Cagney Cc: Jim Blandy , elena@cygnus.com, James Wilson , gdb-patches@sourceware.cygnus.com Subject: Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) Date: Mon, 19 Jun 2000 19:13:00 -0000 Message-id: <200006200213.TAA22932@wilson.cygnus.com> References: <394ED0B7.EFE765A8@cygnus.com> X-SW-Source: 2000-06/msg00239.html Content-length: 429 Um, again, shouldn't this be LONGEST? What is LONGEST, what are the rules for its use, and what are the implications of trying to use it? I am aware that my patches aren't going to work for cross debuggers from 32-bit hosts to 64-bit targets, but right now I'm not worried about that. I need to get the native 64-bit debugger working correctly, and I don't have time at the moment to worry about the cross debugger case. Jim >From ac131313@cygnus.com Mon Jun 19 19:16:00 2000 From: Andrew Cagney To: Ulf Carlsson Cc: Alan Modra , BINUTILS Patches , GDB Patches Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 19:16:00 -0000 Message-id: <394ED3B3.E5A18E2C@cygnus.com> References: <394EC637.24300B87@cygnus.com> <14670.52424.697477.308492@calypso.engr.sgi.com> X-SW-Source: 2000-06/msg00240.html Content-length: 1654 Ulf Carlsson wrote: > > Hi Andrew, > > > > > The attatched patch changes the MIPS ELF32 backend so that it is more > > > > likely to return a sign-extended offset. At present the ELF backend > > > > returns sign-extended symbol table values but not sign extended debug > > > > information. > > > > > > Hi Andrew, > > > Would it be better to just change ecoff_swap_sym_in? It seems like > > > this would achieve what you want, and not risk breaking quite so much. > > > I'm worried about what happens if things like PDR.adr get changed from > > > 0xa0000000 to 0xffffffffa0000000. > > > > Thats why I'm asking :-) Remember though, on the MIPS platform, if > > ``PDR.adr'' is an address then, the canonical form of the value > > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. > > GDB and BFD have, for too many years, been bribed and cajoled into > > perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now > > decided to come clean on this matter (and purge an amazing amount of > > bogus code :-). > > On a 64-bit MIPS processor 32-bit addresses are of course sign > extended, but this shouldn't concern the 32-bit BFD backend for MIPS > in any way. Whether we sign extend the addresses or not shouldn't > make any difference except in our internal representation of the > bfd_vma. I may be wrong though! FYI, it certainly makes a mess of the symbol table lookup code. At one end of GDB the MIPS processor (with those 64 bit registers being used in the n32 ABI say) is providing sign extended register values while at the other end BFD is giving GDB, er, inconsistent values. Andrew >From ac131313@cygnus.com Mon Jun 19 19:23:00 2000 From: Andrew Cagney To: Alan Modra Cc: BINUTILS Patches , GDB Patches Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 19:23:00 -0000 Message-id: <394ED588.3945491@cygnus.com> References: X-SW-Source: 2000-06/msg00241.html Content-length: 1701 Alan Modra wrote: > > On Tue, 20 Jun 2000, Andrew Cagney wrote: > > > > I'm worried about what happens if things like PDR.adr get changed from > > > 0xa0000000 to 0xffffffffa0000000. > > > > Thats why I'm asking :-) Remember though, on the MIPS platform, if > > ``PDR.adr'' is an address then, the canonical form of the value > > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. > > GDB and BFD have, for too many years, been bribed and cajoled into > > perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now > > decided to come clean on this matter (and purge an amazing amount of > > bogus code :-). > > Well, it's the likelihood of other "bogus code" existing in binutils that > assumes addresses are _not_ sign extended that worries me. If you work to > the "You break it, you fix it" rule, then you may be taking on quite a bit > of work :-) I can help to an extent, however, to be honest, I'm having enough fun just re-stablizing the the GDB side of the MIPS. Consequently I'd be focusing on GDB specific problems. People on the BFD/MIPS side will need to be willing to help if there is fallout. > > Any way I've attached a revised patch. I wasn't ruthless enough the > > first time.... With this revision the linker appears to work :-) > > Testing is continuing. > > There's an ECOF_ typo still in a comment. Thanks. > > I guess the question for BFD people is, is this the correct approach to > > fixing this bug? > > I'd like to hear Ian's comments on this before you check it in. Ian has a long memory (Nick does to :-) and both would be very familar with the underlying problems and the very long history that is behind this :-) Andrew >From jimb@zwingli.cygnus.com Mon Jun 19 19:37:00 2000 From: Jim Blandy To: Michael Snyder Cc: gdb-patches@sourceware.cygnus.com Subject: Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) Date: Mon, 19 Jun 2000 19:37:00 -0000 Message-id: References: <200006090053.RAA14301@ada.cygnus.com.cygnus.com> <3949479C.22B3@cygnus.com> X-SW-Source: 2000-06/msg00242.html Content-length: 1973 > Jim (Blandy), one of the two or three changes that you've just made > in dwarf2read.c has broken shared libs on Solaris. > > Please try running shlib-call.exp Looks okay to me: cd ~/cygnus/sun4u/sourceware/gdb/main/native/build/ make check-gdb RUNTESTFLAGS=shlib-call.exp Making a new config file... Nothing to be done for all... rootme=`pwd`; export rootme; \ srcdir=/home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/testsuite ; export srcdir ; \ EXPECT=`if [ -f ${rootme}/../../expect/expect ] ; then echo ${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT ; \ LD_LIBRARY_PATH=$rootme/../../expect:$rootme/../../libstdc++:$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd:$rootme/../../opcodes:$LD_LIBRARY_PATH; \ export LD_LIBRARY_PATH; \ if [ -f ${rootme}/../../expect/expect ] ; then \ TCL_LIBRARY=${srcdir}/../../tcl/library ; \ export TCL_LIBRARY ; fi ; \ runtest shlib-call.exp Test Run By jimb on Mon Jun 19 21:35:19 2000 Native configuration is sparc-sun-solaris2.5.1 === gdb tests === Using /home/jimb/testing/boards/standard.exp as standard board description file for build. Using /home/jimb/testing/boards/standard.exp as standard board description file for host. Schedule of variations: unix Running target unix Using /home/jimb/testing/boards/standard.exp as standard board description file for target. Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file. Running /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/testsuite/gdb.base/shlib-call.exp ... === gdb Summary === # of expected passes 19 /stone/jimb/cygnus/sun4u/sourceware/gdb/main/native/build/gdb/testsuite/../../gdb/gdb version 5.0 -nx Compilation finished at Mon Jun 19 21:35:28 >From geoffk@cygnus.com Mon Jun 19 20:08:00 2000 From: Geoff Keating To: ulfc@calypso.engr.sgi.com Cc: ac131313@cygnus.com, alan@linuxcare.com.au, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 20:08:00 -0000 Message-id: <200006200307.UAA10516@localhost.cygnus.com> References: <394EC637.24300B87@cygnus.com> <14670.52424.697477.308492@calypso.engr.sgi.com> X-SW-Source: 2000-06/msg00243.html Content-length: 653 > From: Ulf Carlsson > Date: Mon, 19 Jun 2000 18:45:44 -0700 (PDT) > On a 64-bit MIPS processor 32-bit addresses are of course sign > extended, but this shouldn't concern the 32-bit BFD backend for MIPS > in any way. Whether we sign extend the addresses or not shouldn't > make any difference except in our internal representation of the > bfd_vma. I may be wrong though! The 64-bit MIPS machines often use the 32-bit ELF format, typically because they have 32-bit memory addresses (I forget whether trying to access 0x0000000087654321 gives you 0xffffffff87654321 or a trap). -- - Geoffrey Keating >From ian@zembu.com Mon Jun 19 20:39:00 2000 From: Ian Lance Taylor To: alan@linuxcare.com.au Cc: ac131313@cygnus.com, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 20:39:00 -0000 Message-id: <20000620033908.18201.qmail@daffy.airs.com> References: X-SW-Source: 2000-06/msg00244.html Content-length: 1140 Date: Tue, 20 Jun 2000 11:50:26 +1000 (EST) From: Alan Modra > > I'm worried about what happens if things like PDR.adr get changed from > > 0xa0000000 to 0xffffffffa0000000. > > Thats why I'm asking :-) Remember though, on the MIPS platform, if > ``PDR.adr'' is an address then, the canonical form of the value > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. > GDB and BFD have, for too many years, been bribed and cajoled into > perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now > decided to come clean on this matter (and purge an amazing amount of > bogus code :-). > I guess the question for BFD people is, is this the correct approach to > fixing this bug? I'd like to hear Ian's comments on this before you check it in. This is all due to a long-ago decision to ship support for a 64-bit MIPS chip using a 32-bit MIPS target. I think that sign extending pdr.ADR is probably right, since that is how 32 bit addresses are treated by the relocation routines. But the real fix is to use a 64-bit MIPS target. Ian >From ian@zembu.com Mon Jun 19 20:41:00 2000 From: Ian Lance Taylor To: geoffk@cygnus.com Cc: ulfc@calypso.engr.sgi.com, ac131313@cygnus.com, alan@linuxcare.com.au, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 20:41:00 -0000 Message-id: <20000620034102.18244.qmail@daffy.airs.com> References: <394EC637.24300B87@cygnus.com> <14670.52424.697477.308492@calypso.engr.sgi.com> <200006200307.UAA10516@localhost.cygnus.com> X-SW-Source: 2000-06/msg00245.html Content-length: 973 Date: Mon, 19 Jun 2000 20:07:59 -0700 From: Geoff Keating > From: Ulf Carlsson > Date: Mon, 19 Jun 2000 18:45:44 -0700 (PDT) > On a 64-bit MIPS processor 32-bit addresses are of course sign > extended, but this shouldn't concern the 32-bit BFD backend for MIPS > in any way. Whether we sign extend the addresses or not shouldn't > make any difference except in our internal representation of the > bfd_vma. I may be wrong though! The 64-bit MIPS machines often use the 32-bit ELF format, typically because they have 32-bit memory addresses (I forget whether trying to access 0x0000000087654321 gives you 0xffffffff87654321 or a trap). I think the real reason this happens is historical--because we didn't have a 64-bit MIPS format when we started supporting 64-bit MIPS chips. I don't think there is any particularly legitimate reason to use a 32-bit format for a 64-bit chip. Ian >From kevinb@cygnus.com Tue Jun 20 00:14:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFC] PARAMS elimination: tui/tuiIO.c Date: Tue, 20 Jun 2000 00:14:00 -0000 Message-id: <1000620071434.ZM523@ocotillo.lan> References: <1000616022019.ZM17748@ocotillo.lan> X-SW-Source: 2000-06/msg00246.html Content-length: 229 On Jun 15, 7:20pm, Kevin Buettner wrote: > More PARAMS elminiation... I'll wait two days for comments / objections > before committing the changes below. > > * tui/tuiIO.c: Eliminate use of PARAMS from this file. Committed. >From kevinb@cygnus.com Tue Jun 20 00:23:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: [PATCH RFC] PARAMS elimination: tui/tuiSourceWin.h Date: Tue, 20 Jun 2000 00:23:00 -0000 Message-id: <1000620072300.ZM544@ocotillo.lan> X-SW-Source: 2000-06/msg00247.html Content-length: 1131 More PARAMS elimination... I'll wait for two days for comments / objections before committing the changes below. (The only file left after this one is copying.awk.) * tuiSourceWin.h: Eliminate use of PARAMS from this file. Index: tui/tuiSourceWin.h =================================================================== RCS file: /cvs/src/src/gdb/tui/tuiSourceWin.h,v retrieving revision 1.2 diff -u -r1.2 tuiSourceWin.h --- tuiSourceWin.h 2000/05/28 01:12:42 1.2 +++ tuiSourceWin.h 2000/06/20 07:18:29 @@ -6,10 +6,10 @@ extern void tuiDisplayMainFunction (void); -extern void tuiUpdateSourceWindow PARAMS - ((TuiWinInfoPtr, struct symtab *, Opaque, int)); -extern void tuiUpdateSourceWindowAsIs PARAMS - ((TuiWinInfoPtr, struct symtab *, Opaque, int)); +extern void tuiUpdateSourceWindow (TuiWinInfoPtr, struct symtab *, Opaque, + int); +extern void tuiUpdateSourceWindowAsIs (TuiWinInfoPtr, struct symtab *, Opaque, + int); extern void tuiUpdateSourceWindowsWithAddr (Opaque); extern void tui_vUpdateSourceWindowsWithAddr (va_list); extern void tuiUpdateSourceWindowsWithLine (struct symtab *, int);