Re: MIPS dwarf2 location lists

[Daniel Jacobowitz <dan at codesourcery dot com>]

On Thu, Feb 18, 2010 at 05:47:32PM +0100, Ulrich Weigand wrote:
> On Cell, the GDB addresses encode the SPU ID for addresses within
> SPU contexts attached to the process.  In the target format (which
> is also used in object files, including DWARF addresses etc.), an
> address is a plain SPU local store address.
> 
> When gdbarch_integer_to_address is called, we attach the SPU ID
> into the high word of the 64-bit CORE_ADDR; for example, an SPU
> local store address of 0x3f000 in SPU context #7 gets encoded
> into a CORE_ADDR value of 0x800000070003f000.
> 
> gdbarch_integer_to_address is the right place to do this, because
> we want the transformation to also happen for addresses entered
> as literals on the command line, for example.

As an aside, I've been thinking about this model.  We have grown a lot
of support for multiple address spaces since this was implemented.
Is that something we can use instead of overloading CORE_ADDR bits?
It'd be a big project; I think values would need to carry an address
space around.  Anyway, back to our topic.

> But this means that we need to distinguish very clearly between
> *addresses* and *offsets*.  A transformation like the above must
> only be done on base addresses; offsets are simply treated as
> integers that are added onto an already transformed base address,
> and must not themselves be transformed as well.
> 
> However, it seems that there is still one choice that isn't
> fully specified: should an offset be treated as *signed* or
> *unsigned* integer?  The DWARF standard is silent on this;
> maybe it assumes this doesn't matter as address arithmetic
> on these offsets is supposed to be performed within the DWARF
> address size precision? 

That's my guess.  We really should be doing CORE_ADDR arithmetic in an
architecture-specific precision.  If we did that, the question of
whether the CORE_ADDR is sign or zero extended would become an
implementation detail.

> Masking high bits off will actually break Cell, because it would
> cause the SPU ID to be simply ignored in comparisons.  In the past,
> the only places where addresses were truncated according to
> gdbarch_addr_bit did so to output an address in human- or machine-
> readable string form (as user output, or remote/monitor protocol
> elements).  At these points, address truncation in a sense serves
> as the reverse of the gdbarch_integer_to_address transform; this
> is exactly what's needed on Cell.

Oh, great.  So we can't sign extend, zero extend, or mask.  And
wraparound offsets are going to completely confuse the situation.

My best idea is to separate addresses and offsets - as you've
suggested, and I think Mark suggested this week also - and define
offsets as sign extended.  I'm not entirely confident that will work,
though, because when we get an offset we don't know if it's supposed
to wrap around or not.  If you have a binary linked at zero (because
it's position-independent, say), and it's loaded at 0x90000000, then
is that a positive or negative offset?  On a 32-bit platform, with
64-bit CORE_ADDR, if you define that as a positive offset you'll break
MIPS.  If you define it as a negative offset you'll break x86 and
SPU (it'll decrement the SPU number in the address).  Obviously I'd
have to pick a different example for it to make sense on SPU, since
they have a tiny local store.

> As to build_section_addr_info_from_objfile, I'm wondering what problem the
> masking was supposed to address:
> 
>       sap->other[i].addr = (bfd_get_section_vma (objfile->obfd, sec)
>                             + objfile->section_offsets->offsets[i]) & mask;
> 
> It looks like this happens if an object is loaded below its original load
> address (I guess this can happen if a prelinked object is loaded somewhere
> else), and thus the section_offsets need to be negative, which may not
> work as intended as CORE_ADDR is unsigned.  It seems that whoever computes
> the section_offsets in this particular case ought to be able to compensate ...

FWIW, the patch was here:

http://sourceware.org/ml/gdb-patches/2009-11/msg00173.html

-- 
Daniel Jacobowitz
CodeSourcery