This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [rfc] For mips, sign-extended ecoff offsets
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [rfc] For mips, sign-extended ecoff offsets
- From: Ulf Carlsson <ulfc at calypso dot engr dot sgi dot com>
- Date: Mon, 19 Jun 2000 18:45:44 -0700 (PDT)
- Cc: Alan Modra <alan at linuxcare dot com dot au>, BINUTILS Patches <binutils at sourceware dot cygnus dot com>, GDB Patches <gdb-patches at sourceware dot cygnus dot com>
- References: <Pine.LNX.4.21.0006200100160.12273-100000@front.linuxcare.com.au><394EC637.24300B87@cygnus.com>
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!
Ulf