This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Use the address mask with addresses for SREC, etc.
- From: "Maciej W. Rozycki" <macro at mips dot com>
- To: Jim Blandy <jimb at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Nigel Stephens <nigel at mips dot com>, Chris Dearman <chris at mips dot com>, "Maciej W. Rozycki" <macro at linux-mips dot org>
- Date: Wed, 25 Jul 2007 19:11:49 +0100 (BST)
- Subject: Re: Use the address mask with addresses for SREC, etc.
- References: <Pine.LNX.4.61.0707241740390.20726@perivale.mips.com> <m3bqe0ig5t.fsf@codesourcery.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