R_SPARC_RELATIVE vs R_SPARC_UA32 & unaligned unwind tables - again

[Jakub Jelinek]

On Wed, Dec 19, 2001 at 09:59:25AM +0100, Jakub Jelinek wrote:
> On Wed, Dec 19, 2001 at 02:52:11PM +1030, Alan Modra wrote:
> > #if !defined RTLD_BOOTSTRAP && !defined RESOLVE_CONFLICT_FIND_MAP
> >       const Elf32_Sym *const refsym = sym;
> > #endif
> >       Elf32_Addr value;
> > #ifndef RESOLVE_CONFLICT_FIND_MAP
> >       if (sym->st_shndx != SHN_UNDEF &&
> > 	  ELF32_ST_BIND (sym->st_info) == STB_LOCAL)
> > 	value = map->l_addr;
> 
> I don't know exactly what is this for, but in powerpc/dl-machine.h above
> similar code is:
> 
>   /* The condition on the next two lines is a hack around a bug in Solaris
>      tools on Sparc.  It's not clear whether it should really be here at all,
>      but if not the binutils need to be changed.  */
> 
> If this is what Solaris used to do in their ld.so (which wouldn't surprise
> me, theer have been other ld.so bugs found in the past), then IMHO the best things
> to fix this up are:
> 1) check all shared libraries on say 2 different sparc linux distros to
>    search for section relative dynamic relocs
> 2) if none are found, kill the above code from glibc
> 3) change binutils, so that it never creates section relative dynamic relocs
>    for shared libs (because ld.so cannot be trusted). It could change the
>    dynamic reloc to ELF32_R_INFO (0, non-R_SPARC_RELATIVE) and adjust addend
>    accordingly.

Ok, after checking the real situation:
1) many libraries do so (e.g. all with non-fPIC objects)
2) glibc code matches what does Solaris 8 ld.so and what Solaris ld creates:
   relocs against STB_LOCAL symbols have addend which is relative to
   library VMA, not the actual STB_LOCAL symbol value
As I have no access to Solaris 2.5, I cannot tell more. Is it just
R_SPARC_UA32 which doesn't work properly (e.g. if you put sethi %hi(.data + 35), %o0
into some writeable section (Solaris ld doesn't want to create DT_TEXTREL
apparently), does it resolve properly)?

	Jakub