Re: R_SPARC_RELATIVE vs R_SPARC_UA32 & unaligned unwind tables - again

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Dec 18, 2001 at 09:31:35PM -0500, DJ Delorie wrote:
> 
> Ok, I seem to have bumped into a "this just isn't possible" scenario.
> 
> We create unaligned 32-bit pointers in unwind tables (specifically,
> in the augmentation fields for context->lsda in gcc/unwind-dw2.c).
> 
> If these pointers are in a shared library, the dynamic linker needs to
> adjust them according to where the shared library is loaded.
> 
> However, the only reloc available for that is R_SPARC_RELATIVE, and it
> requires aligned data.  If you try to use it with unaligned data,
> ld.so aborts.  If you don't use it, unwinding causes aborts because
> the pointer points to the wrong place.
> 
> Could we make that pointer fde-relative or something, so that ld.so
> doesn't need to adjust it?  Or make it aligned?  I can't think of any
> other fix, unless there's some other R_SPARC_* reloc that does what's
> needed here.

Yes, we surely should make it fde-relative.
There are 2 ways of doing this:
1) (the preferable) - I need to revive a patch to introduce
   %r_disp{8,16,32,64} and %r_plt{32,64} (the former is Solaris way
   of doing x-.)
2) the .eh_frame code is able to automatically make relative
   initial_location and LSDA pointers from absolute ones (provided gcc
   creates an R resp. L augmentation), but this is currently disabled
   since some ELF backends need to be slightly changed for this.
The former is preferable, since 2) would only be able to change
SPARC 64-bit DW_EH_PE_absptr|DW_EH_PE_udata8 to
DW_EH_PE_pcrel|DW_EH_PE_udata8, while with 1) it could be
DW_EH_PE_pcrel|DW_EH_PE_sdata4.

As for what's going on with R_SPARC_UA32 in your case, I'll check it out
today if time permits.

	Jakub