Re: [RFC] DWARF 2 address size != pointer size

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Fred Fish <fnf@specifix.com>
> Date: Wed, 10 May 2006 14:24:10 -0400
> 
> For at least one target, MIPS using the o64 ABI with -mlong64, the
> target DWARF2 address size used in the DWARF info (32 bit) is not the
> same as the target pointer size (64 bit).

Unbelievable.  As if there aren't enough ABI's for MIPS yet.  But how
can this work?  If the pointers are really 64-bit, how can they be
encoded in the 32-bit DWARF2 adresses?

> For example, below are some fragments from dumping the DWARF info
> for a simple test case:
> 
>   Compilation Unit @ 0:
>    Length:        175
>    Version:       2
>    Abbrev Offset: 0
>    Pointer Size:  4	
>  <1><91>: Abbrev Number: 3 (DW_TAG_base_type)
>      DW_AT_name        : long int
>      DW_AT_byte_size   : 8
>  <1><b0>: Abbrev Number: 4 (DW_TAG_pointer_type)
>      DW_AT_byte_size   : 8
> 
> Note that the header records the address size as 4, which is the
> number of bytes written to the DWARF info when writing addresses, but
> that the target pointer size is 8.
> 
> Currently gdb computes the DWARF info address size as:
> 
> 	TARGET_ADDR_BIT / TARGET_CHAR_BIT
> 
> Given that the address size is actually recorded in the compilation
> unit header, I believe the best solution would be to use that recorded
> value somehow.  I spent a couple days looking for an easy way to tie
> the address size to DWARF expressions that were recorded for later
> evaluation, but didn't come up with anything clean enough to submit.
> 
> Another way to divorce the DWARF address size from the TARGET_ADDR_BIT
> is to add another gdbarch paramter, accessed as TARGET_DWARF_ADDR_BIT.
> I've attached a patch that does that.  It's simple, but not my first
> choice for solving the problem.
> 
> Comments?

I think introducing TARGET_DWARF_ADDR_BIT is a mistake if the debug
info already encodes the info.