Re: Why does mips define elf_backend_sign_extend_vma to true?

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

H . J . Lu wrote:
[snip]
> >  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.

This doesn't make it clearer (at least to me) why it shouldn't be fine.

> 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.

Let me recapitulate:
64bit BFD is required for e.g. debugging for a 64bit target. In this
case, sign-extension is needed for elf32-mips. If the very same object
is running on a 32bit target, the sign extended bits are irrelevant.

So AFAICS you prefer to give BFD a notion of the actual target's
register width, while Maciej et al. prefer to truncate the output
to fit. Instinctively, I would also prefer the latter.


Thiemo