This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: DWARF2 FDE Address Mismatch
- From: Daniel Jacobowitz <drow at false dot org>
- To: Matt Kern <matt dot kern at undue dot org>
- Cc: gdb at sourceware dot org
- Date: Fri, 1 Jun 2007 09:43:55 -0400
- Subject: Re: DWARF2 FDE Address Mismatch
- References: <20070601122049.GA32523@pling.qwghlm.org>
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