This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfa] frame address size incorrect if address size != ptr size
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