Re: MIPS dwarf2 location lists

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Daniel Jacobowitz wrote:
> 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.

Yes, this would be nice to fix.  One problem is that we'd not just
need multiple address spaces, but also multiple program spaces --
each SPU context has its own object file(s) loaded.  And even in
current GDB, we still have fundamentally just one program space
per inferior; rooting out the current_program_space global will
be a nontrivial effort.

Values (at least lval_memory values) would certainly need to carry
an address space.  For values of pointer type, we'd also need the
address space of the object pointed to -- this may be different from
the one where the pointer itself resides.

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

Actually, I think this can be made to work.  Basic rule needs to be
that an offset is always computed as the difference between two addresses,
where addresses have undergone the appropriate platform-specific treatment.

So in your example, link address zero would be CORE_ADDR 0 on both i386
and mips (note that even zero would actually become something like
0x8000000700000000 on spu!), but the load address 0x90000000 would be
CORE_ADDR 0x90000000 on i386 but 0xffffffff90000000 on mips.  Subtracting
the link address would thus result in the appropriate offset for the
platform.

Or, to look at it differently, if we compute the offset to move A to B
as (B - A), adding that offset to A will always result in B again, as
long as both the subtraction and the addition are performed on plain
CORE_ADDR values.  As long as addresses A and B are always computed
like addresses on the platform need to be, we should be fine.

(There is the theoretical case that if we apply the offset (B - A) to
some address that is itself offset, like A + x, we could get wrong
overflow.  But this can really only occur if a single objfile is
wrapped around the top of memory -- I don't think this is really
possible.)


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

If the offsets were computed as outlined above, it seems to me this should
always work.  It's not quite clear from the patch description where this
is assumption is violated ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com