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

Mark Kettenis
2006-05-12T19:51:14Z

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