Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux)

[Andrew Cagney <ac131313@cygnus.com>]

[to/cc re-aranged]

James Wilson wrote:

> 2000-06-19  James E. Wilson  <wilson@cygnus.com>

>         * 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 <wilson@wilson.cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Jim Blandy <jimb@cygnus.com>, elena@cygnus.com, James Wilson <wilson@cygnus.com>, 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 <ac131313@cygnus.com>
To: Ulf Carlsson <ulfc@calypso.engr.sgi.com>
Cc: Alan Modra <alan@linuxcare.com.au>, BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
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: <Pine.LNX.4.21.0006200100160.12273-100000@front.linuxcare.com.au> <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 <ac131313@cygnus.com>
To: Alan Modra <alan@linuxcare.com.au>
Cc: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
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: <Pine.LNX.4.21.0006201128050.12273-100000@front.linuxcare.com.au>
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 <jimb@zwingli.cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
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: <npk8flf57z.fsf@zwingli.cygnus.com>
References: <200006090053.RAA14301@ada.cygnus.com.cygnus.com> <npk8frhmkp.fsf@zwingli.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 <geoffk@cygnus.com>
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: <Pine.LNX.4.21.0006200100160.12273-100000@front.linuxcare.com.au> <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 <ulfc@calypso.engr.sgi.com>
> 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 <geoffk@cygnus.com>
From ian@zembu.com Mon Jun 19 20:39:00 2000
From: Ian Lance Taylor <ian@zembu.com>
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: <Pine.LNX.4.21.0006201128050.12273-100000@front.linuxcare.com.au>
X-SW-Source: 2000-06/msg00244.html
Content-length: 1140

   Date: Tue, 20 Jun 2000 11:50:26 +1000 (EST)
   From: Alan Modra <alan@linuxcare.com.au>

   > > 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 <ian@zembu.com>
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: <Pine.LNX.4.21.0006200100160.12273-100000@front.linuxcare.com.au> <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 <geoffk@cygnus.com>

   > From: Ulf Carlsson <ulfc@calypso.engr.sgi.com>
   > 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 <kevinb@cygnus.com>
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> <kevinb@cygnus.com>
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 <kevinb@cygnus.com>
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);