Re: Why does mips define elf_backend_sign_extend_vma to true?

["H . J . Lu" <hjl@lucon.org>]

On Wed, Aug 08, 2001 at 10:11:29AM +0200, Maciej W. Rozycki wrote:
> On Tue, 7 Aug 2001, H . J . Lu wrote:
> 
> > > Besides, things aren't broken.  Use a 64-bit BFD and 
> > > you _should_ get sign-extension for MIPS.
> > 
> > That is wrong for MIPS I/II even if BFD is 64bit for whatever reason.
> 
>  Sign-extension is fine.  I think what you really want is to truncate
> addresses in the output of certain programs such as nm and objdump to 32
> bits if the output BFD is elf32-*mips.  It's on my to-do list for some
> time, but don't hold your breath (i.e. feel free to do it yourself ;-) ). 

It is not fine at all. The change is to address the problem in

http://sources.redhat.com/ml/binutils/1999-11/msg00067.html

which said

GDB encounters situtations (c.f. assorted mips targets) where the object
file contains 32 bit addresses but the target has a 64 bit address
space.  The 32 address values being implicitly zero or sign extended to
64 bits.  GDB needs to know what the object file format assumed (or
didn't in some case) is doing so that it can correctly do things like
compares.

The key here is "the target has a 64 bit address space." It is not the same
as the gdb/nm/objdump configured with the 64bit BFD. The approach is wrong.

It seems that I am the only one who thinks it is incorrect. I will find a
simple way to get around it in my binutils/gdb.

If people agreee it is wrong, I am willing to spend time finding a soluton
acceptable for everyone.


H.J.