Re: DWARF-2 and address sizes

[Daniel Jacobowitz <drow@mvista.com>]

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 wonder if MIPS64 Linux kernels do this, since they're technically
ELF32?  Hmm, probably not.

GCC defines the address size as a constant (4) on ip2k and stormy16,
and in terms of pointer size elsewhere.  I don't know any platform
where objects with different pointer sizes can be linked together, and
it seems dubiously useful at best.

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.

> But I don't think you'll encounter a case where cu_header->addr_size 
> isn't locally consistent with the rest of the file.
> 
> > Do we have to
> >worry about a binary in which different compilation units (or different
> >shared objects, even) have a different value for this?
> 
> See if binutils allows it.  If not ...

Binutils, sadly, doesn't care.  It only uses the address size within a
compilation unit.

> 
> >If the consensus is "no, that's too stupid to be allowed to live", then 
> >this
> >gets much easier.
> >
> >(Then consider DW_OP_deref_size; this is a fun one, since it has to be
> >zero-extended to the size of an address on the target machine according to
> >the spec, and then in GDB it may have to be zero or sign extended to the
> >size of a CORE_ADDR for storage.  I haven't tested any of this on MIPS yet
> >and I don't want to, damn it.  I don't know of any MIPS ABI with multiple
> >pointer sizes, and you can't link different ABIs, so encountering
> >DW_OP_deref_size is probably impossible.  I hope.)
> 
> Have a look at dwarf2read.c:read_address() the existing code already 
> handles one case of this.

Yes.  I don't know if it sign extends properly in all cases - I guess
it does if signed_address_p always matches whether a CORE_ADDR is a
signed type, but that's dubious.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer