Re: [rfa] frame address size incorrect if address size != ptr size

[Corinna Vinschen <vinschen@redhat.com>]

On Aug  6 18:27, Ulrich Weigand wrote:
> Corinna Vinschen wrote:
> > The problem for XStormy16 in 16 bit pointer mode is that a pointer is
> > not able to point to every place in the 24 bit address space the CPU can
> > address.  For function pointers that means that the target potentially
> > has to use a jump table.  For the stack that means it is restricted to
> > the first 64K RAM.
> > 
> > So, afaics, the unwind-pe.h code only works correct for XStormy16, if
> > either the application fits into the first 64K of memory, or if
> > DW_EH_PE_absptr is not used, rather DW_EH_PE_pcrel, DW_EH_PE_textrel,
> > DW_EH_PE_datarel, or DW_EH_PE_funcrel.  Oh, and then there's the
> > type of _Unwind_Ptr, which would have to be big enough, 32 bit.
> 
> OK, I see what you mean.  So if we were to enable DWARF EH for XStormy16,
> we'd either have to do what you just described (all of which should in
> principle be doable), or else add something new to support larger "pointer"
> or address types.  I'd assume this might then be a new encoding type ...
> 
> In any case, I'd still say that GDB today ought to match what GCC today
> does, which is that DW_EH_PE_absptr encoding uses target-format pointers.
> If and when GCC is extended, say to support another encoding type, we'd
> then likewise extend GDB to support that new feature.
> 
> 
> > > I'd reword this to make clear that this value is *not* used for .eh_frame,
> > > but solely for .debug_frame.
> > 
> > Ok, will do.  I'd just like to put the discussion to an end, first.
> > Just tell me what you think of what I wrote above.
> 
> Does the above make sense to you?

Yes, fine with me, but that also means the comment I added makes still
sense...


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat