Re: DWARF2 FDE Address Mismatch

[Matt Kern <matt dot kern at undue dot org>]

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/