Re: DWARF-2 and address sizes

[Andrew Cagney <ac131313@redhat.com>]

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

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

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

Andrew