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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Corinna Vinschen wrote:
> On Aug  6 16:50, Ulrich Weigand wrote:
> > The difference between .eh_frame and .debug_frame is really fundamental;
> > .eh_frame holds *pointer* values in target "void *" format; while
> > .debug_frame holds *address* values using the same format as the rest
> > of the DWARF debug sections.
> > 
> > Therefore we will definitely have to make a distinction between the two.
> > If you have another suggestion how to achieve that, I'd certainly be
> > interested ...
> 
> I understand what you're up to, but to me this means that the above code
> from unwind-pe.h is potentially not usable for certain small targets,
> unless some conditions are met.
> 
> As it is the one example I really know well, let's stick to XStormy16
> for now.
> 
> 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?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com