From: Daniel Jacobowitz <drow@false.org>
To: Matt Kern <matt.kern@undue.org>
Cc: gdb@sourceware.org
Subject: Re: DWARF2 FDE Address Mismatch
Date: Fri, 01 Jun 2007 13:44:00 -0000 [thread overview]
Message-ID: <20070601134355.GC2734@them.org> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2007-06-01 13:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-01 12:20 Matt Kern
2007-06-01 13:44 ` Daniel Jacobowitz [this message]
2007-06-01 14:26 ` Matt Kern
2007-06-01 14:55 ` Matt Kern
2007-06-01 17:14 ` Daniel Jacobowitz
2007-06-05 10:37 ` Matt Kern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070601134355.GC2734@them.org \
--to=drow@false.org \
--cc=gdb@sourceware.org \
--cc=matt.kern@undue.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox