Re: Use the address mask with addresses for SREC, etc.

["Maciej W. Rozycki" <macro@mips.com>]

On Wed, 25 Jul 2007, Jim Blandy wrote:

> It's my understanding that addresses are signed on MIPS architectures,
> and thus 32-bit SREC files are only capable of addressing locations
> 0xffffffff80000000 -- 0x000000007fffffff.  And that the issue you're
> fixing here arises from BFD handing you addresses read from an SREC
> file (which is using 32-bit addresses) in the 0x80000000 -- 0xffffffff
> range.  Is that right?

 That is correct.  The same applies to the HEX formats.  I gather this is 
more or less the reason dump.exp skips testing these formats for pure 
64-bit targets (but MIPS is "impure").  Note that the actual MIPS target 
may be 32-bit making the notion of the signedness of addresses irrelevant, 
but BFD is still 64-bit causing trouble inbetween.

> I'm not too happy with complicating code in GDB because BFD is
> providing it with the wrong addresses.  I have to imagine the same
> thing would happen elsewhere.  When BFD reads the SREC file, does it

 Well, the issue hits here and there across the whole src/ tree every once 
in a while.  It looks like MIPS is about the only oddball to have its 
addresses signed -- which is actually the result of how the (smart) 
extension from a 32-bit to a 64-bit CPU has been made (FYI, bits 31 and 63 
differentiate between kernel- and user-mode addresses for 32-bit and 
64-bit addressing respectively).

> have any idea that it's a MIPS SREC file?  It looks like
> bfd_get_sign_extend_vma doesn't know about MIPS SREC targets; would
> fixing that, and then bfd/srec.c, help us get the right addresses into
> the BFD?

 Well, AFAICS SREC and HEX files are target-agnostic, much like "binary" 
BFD.  The only possible way of handling it in BFD itself would be by 
sign-extending addresses at the "right point" if the destination BFD 
implies bfd_get_sign_extend_vma() true.  I somehow dislike hardcoding the 
"right point" in {ihex,srec,tekhex}.c, but given these formats appear to 
me as pure 32-bit, perhaps chosing bit 31 as the "right point" is OK.  
What do you think?

  Maciej