DWARF2 FDE Address Mismatch

DWARF2 FDE Address Mismatch

[Matt Kern]

I am in the process of porting a new MCU/processor to gcc/gdb.  It has a
a Harvard architecture with a 24 bit code address space (word aligned
instructions) and a 16 bit data address space.  Our toolchain emits ELF
binaries with code and data VMAs based at zero.  The program loads as
though it is a ROM image located entirely in code space.

The setup we have gone for involves having all pointers be 16 bits.
Code pointers actually address "trampolines" to the respective
functions.  Our preferred debug format is DWARF2;  we have therefore set
DWARF2_ADDR_SIZE to 4 in order to correctly represent our full range of
code addresses.  Without this setting, addresses are stored as
POINTER_SIZE / BITS_PER_UNIT == 2 bytes.

The output produced by gcc looks to be correct at this juncture.
However, we have problems loading the DWARF2 info in gdb.  Most notably,
gdb defaults cie->encoding to DW_EH_PE_absptr (which is sizeof(void*) ==
2 bytes).   The encoding can be changed by augmentation, but gcc only
emits this for EH data; DWARF2_ADDR_SIZE applies to non-EH data.

In short it looks like GDB DWARF2 support lacks a mechanism to override
the address size (comparable to DWARF2_ADDR_SIZE in gcc).  Is my
understanding correct?

Regards,
Matt


-- 
Matt Kern
http://www.undue.org/

Re: DWARF2 FDE Address Mismatch

[Daniel Jacobowitz]

On Fri, Jun 01, 2007 at 01:20:49PM +0100, Matt Kern wrote:
> I am in the process of porting a new MCU/processor to gcc/gdb.  It has a
> a Harvard architecture with a 24 bit code address space (word aligned
> instructions) and a 16 bit data address space.  Our toolchain emits ELF
> binaries with code and data VMAs based at zero.  The program loads as
> though it is a ROM image located entirely in code space.
> 
> The setup we have gone for involves having all pointers be 16 bits.
> Code pointers actually address "trampolines" to the respective
> functions.  Our preferred debug format is DWARF2;  we have therefore set
> DWARF2_ADDR_SIZE to 4 in order to correctly represent our full range of
> code addresses.  Without this setting, addresses are stored as
> POINTER_SIZE / BITS_PER_UNIT == 2 bytes.
> 
> The output produced by gcc looks to be correct at this juncture.
> However, we have problems loading the DWARF2 info in gdb.  Most notably,
> gdb defaults cie->encoding to DW_EH_PE_absptr (which is sizeof(void*) ==
> 2 bytes).   The encoding can be changed by augmentation, but gcc only
> emits this for EH data; DWARF2_ADDR_SIZE applies to non-EH data.
> 
> In short it looks like GDB DWARF2 support lacks a mechanism to override
> the address size (comparable to DWARF2_ADDR_SIZE in gcc).  Is my
> understanding correct?

Yes, that looks true.  Perhaps it should be using TARGET_ADDR_BIT
instead.

-- 
Daniel Jacobowitz
CodeSourcery

Re: DWARF2 FDE Address Mismatch

[Matt Kern]

On Fri, Jun 01, 2007 at 09:43:55AM -0400, Daniel Jacobowitz wrote:
> On Fri, Jun 01, 2007 at 01:20:49PM +0100, Matt Kern wrote:
> > ...
> > In short it looks like GDB DWARF2 support lacks a mechanism to override
> > the address size (comparable to DWARF2_ADDR_SIZE in gcc).  Is my
> > understanding correct?
> 
> Yes, that looks true.  Perhaps it should be using TARGET_ADDR_BIT
> instead.

A quick look at GCC tells me:

  * For EH data it uses a potentially arch-specific macro,
    ASM_PREFERRED_EH_DATA_FORMAT() to determine the address siz.  This
    macro is parameterised by code (data, code label, function ptr) and
    global (true if may be affected by dynamic relocs).

  * For non-EH data, DWARF2_ADDR_SIZE is used.

Given that decode_frame_entry_1() has to work with EH and non-EH data, I
would suggest passing eh_frame_p down into read_encoded_value() together
with an analogue for "code".  If we go on to implement EH, then we will
require a target macro that parallels ASM_PREFERRED_EH_DATA_FORMAT().
As far as I can see, this hasn't been an issue until now because most
ports either have types that are void* in size or they don't use DWARF2.

I can do the work.  How do you want to handle the patch though?  Do you
want me to submit something now, or should I hold it in our port until
it matures enough for adoption?

Matt

-- 
Matt Kern
http://www.undue.org/

Re: DWARF2 FDE Address Mismatch

[Matt Kern]

Scratch that.  We should probably do what GCC does and call either
read_encoded_value() or another read function depending upon eh_frame_p.

Matt

On Fri, Jun 01, 2007 at 03:26:13PM +0100, Matt Kern wrote:
> On Fri, Jun 01, 2007 at 09:43:55AM -0400, Daniel Jacobowitz wrote:
> > On Fri, Jun 01, 2007 at 01:20:49PM +0100, Matt Kern wrote:
> > > ...
> > > In short it looks like GDB DWARF2 support lacks a mechanism to override
> > > the address size (comparable to DWARF2_ADDR_SIZE in gcc).  Is my
> > > understanding correct?
> > 
> > Yes, that looks true.  Perhaps it should be using TARGET_ADDR_BIT
> > instead.
> 
> A quick look at GCC tells me:
> 
>   * For EH data it uses a potentially arch-specific macro,
>     ASM_PREFERRED_EH_DATA_FORMAT() to determine the address siz.  This
>     macro is parameterised by code (data, code label, function ptr) and
>     global (true if may be affected by dynamic relocs).
> 
>   * For non-EH data, DWARF2_ADDR_SIZE is used.
> 
> Given that decode_frame_entry_1() has to work with EH and non-EH data, I
> would suggest passing eh_frame_p down into read_encoded_value() together
> with an analogue for "code".  If we go on to implement EH, then we will
> require a target macro that parallels ASM_PREFERRED_EH_DATA_FORMAT().
> As far as I can see, this hasn't been an issue until now because most
> ports either have types that are void* in size or they don't use DWARF2.
> 
> I can do the work.  How do you want to handle the patch though?  Do you
> want me to submit something now, or should I hold it in our port until
> it matures enough for adoption?
> 
> Matt
> 
> -- 
> Matt Kern
> http://www.undue.org/

-- 
Matt Kern
http://www.undue.org/

Re: DWARF2 FDE Address Mismatch

[Daniel Jacobowitz]

On Fri, Jun 01, 2007 at 03:26:13PM +0100, Matt Kern wrote:
> On Fri, Jun 01, 2007 at 09:43:55AM -0400, Daniel Jacobowitz wrote:
> > On Fri, Jun 01, 2007 at 01:20:49PM +0100, Matt Kern wrote:
> > > ...
> > > In short it looks like GDB DWARF2 support lacks a mechanism to override
> > > the address size (comparable to DWARF2_ADDR_SIZE in gcc).  Is my
> > > understanding correct?
> > 
> > Yes, that looks true.  Perhaps it should be using TARGET_ADDR_BIT
> > instead.
> 
> A quick look at GCC tells me:
> 
>   * For EH data it uses a potentially arch-specific macro,
>     ASM_PREFERRED_EH_DATA_FORMAT() to determine the address siz.  This
>     macro is parameterised by code (data, code label, function ptr) and
>     global (true if may be affected by dynamic relocs).
> 
>   * For non-EH data, DWARF2_ADDR_SIZE is used.

For .eh_frame we have to do this funny dance with GCC to determine the
"right" behavior.  For .debug_frame, there is a standard and we should
be following it - and so should GCC.  What does it have to say?  If it
says "the size of an address on the target machine" then we should
probably use TARGET_ADDR_BIT; otherwise I'm not sure.  I think this
format ambiguity has come up before.

-- 
Daniel Jacobowitz
CodeSourcery

Re: DWARF2 FDE Address Mismatch

[Matt Kern]

Okay -- I have a patch which works for our arch.  I haven't tested it on
a stable arch yet though to ensure it doesn't break anything.

The change is to call read_encoded_value() if eh_frame_p is set;
otherwise dwarf2_read_address() is called.  I have modified
dwarf2_read_address to read addresses of size TARGET_ADDR_BIT rather
than TARGET_INT_BIT.

> For .eh_frame we have to do this funny dance with GCC to determine the
> "right" behavior.  For .debug_frame, there is a standard and we should
> be following it - and so should GCC.  What does it have to say?  If it
> says "the size of an address on the target machine" then we should
> probably use TARGET_ADDR_BIT; otherwise I'm not sure.  I think this
> format ambiguity has come up before.

From "7.5.4 Attribute Encodings":

"address     Represented as an object of appropriate size to hold an
             address on the target machine (DW_FORM_addr)."

Matt

-- 
Matt Kern
http://www.undue.org/