Re: [rfc] For mips, sign-extended ecoff offsets

[Andrew Cagney <ac131313 at cygnus dot com>]

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