Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Matt Kern <matt.kern@undue.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb@sourceware.org
Subject: Re: DWARF2 FDE Address Mismatch
Date: Fri, 01 Jun 2007 14:26:00 -0000	[thread overview]
Message-ID: <20070601142613.GA19779@pling.qwghlm.org> (raw)
In-Reply-To: <20070601134355.GC2734@them.org>

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/


  reply	other threads:[~2007-06-01 14:26 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
2007-06-01 14:26   ` Matt Kern [this message]
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=20070601142613.GA19779@pling.qwghlm.org \
    --to=matt.kern@undue.org \
    --cc=drow@false.org \
    --cc=gdb@sourceware.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