Re: DWARF-2 and address sizes

[Jim Blandy <jimb@redhat.com>]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Sat, Feb 01, 2003 at 01:20:17AM -0500, Daniel Berlin wrote:
> > 
> > On Friday, January 31, 2003, at 05:36  PM, Daniel Jacobowitz wrote:
> > 
> > >On Fri, Jan 31, 2003 at 04:59:56PM -0500, Andrew Cagney wrote:
> > >>>[Kevin, I noticed you doing some work in this area re S/390, maybe 
> > >>>you've
> > >>>got a comment?  Anyone else?  I'm grasping at straws.]
> > >>>
> > >>>I'm trying to figure out how to handle addresses in the DWARF 
> > >>>expression
> > >>>evaluator.  First consider DW_OP_deref: the following data is "the 
> > >>>size of
> > >>>an address on the target machine", which I would personally take to 
> > >>>mean
> > >>>cu_header->addr_size.  Is this ever different from 
> > >>>TARGET_ADDRESS_BIT /
> > >>>TARGET_CHAR_BIT, which is what Daniel was originally using?
> > >>
> > >>I can imagine architectures wack-o enough for cu_header->addr_size !=
> > >>TARGET_ADDRESS_BIT / TARGET_CHAR_BIT.  Someone doing a 16 bit port 
> > >>using
> > >>32 bit elf.
> > ...
> > 
> > >I'm willing to document this as an assertion, store the dwarf2 address
> > >size and signedness somewhere global, and bail if I detect a violation.
> > >But I'll skip that for now; it can be a later cleanup.  I've already
> > >got too many pieces in this patch.
> > >
> > 
> > IIRC, I did it some *other* way, and Jim told me to do it with the way 
> > there now.
> > Or is that the other way around (He told me to do it some other way, 
> > rather than what's there now, and i never got to it).
> > I believe I used to use one of the length of one of builtin types, and 
> > he told me to use TARGET_ADDRESS_BIT / TARGET_CHAR_BIT.
> > The archives should say.
> 
> Hmm, I didn't see it in the archives, so maybe I need to look further
> back.  I'll check again.
> 
> Jim, I don't suppose you remember?

I'm pretty sure that I saw the code simply using the whole CORE_ADDR
to do the dereferencing, and that I said it should be changed to use
the target's address size, since, in a gdbarch world, CORE_ADDR could
be larger than a target address.  I don't think I specified whether
one should use cu->addr_size or TARGET_ADDRESS_BIT / TARGET_CHAR_BIT;
I doubt it occurred to me that they might be different.

Given the way cu_header->addr_size is used in the definition of
DW_FORM_addr (section 7.5.4, "Attribute Encodings"), I would expect it
to match the size of a linker symbol value --- since the point is to
provide something that can be relocated.  But every ABI provides
relocs for smaller values, too, so it could be different.

I guess I don't really understand why this is a big deal.  The baton
for the expression should record the addr_size and signed_addr_p from
the compilation unit it came from.  Just use that many bits of
CORE_ADDR, sign-extended as directed.  If this isn't right, we'll find
out eventually.  We don't have any authority here to work from, so
that's the best we can do.

Or am I being too sloppy?