Re: Use dl_iterate_phdr in Solaris 11+ unwinder

[Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>]

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> Solaris 11 gained support for dl_iterate_phdr in build 135, and I've
> lately been working to use it in the libgcc unwinder.
[...]
>
> The patch itself is fairly trivial, and will further be simplified
> before final submission.  I'd like to post the current state of affairs
> to get comments on a couple of issues:
>
> * A considerable part of the patch consists of workarounds for Sun ld
>   bugs:
>
> ** ld currently interprets DW_EH_PE_datarel relative to .eh_frame_hdr
>    instead of .got.  Unfortunately the LSB is unspecific about this, and
>    I've still not found a proper specification, but this is going to be
>    fixed.
>
> ** On SPARC, the search table in .eh_frame_hdr is always empty, so I'm
>    ignoring it right now.
>
> ** I also ran into a GNU ld bug that broke libffi unwind and libjava
>    testing:
>
>    ld/12253	.eh_frame_hdr not properly sorted with mixed .eh_frame encodings
>
>    This is now fixed for binutils 2.22 and will be worked around in
>    libffi.
>
> ** The DT_PLTGOT entry in .dynamic on 32-bit x86 is relocated in glibc
>    (ld-linux.so) by adding the load base, but not by either Solaris or
>    FreeBSD ld.so.  FreeBSD is unaffected, though, since they use the
>    default encoding, DW_EH_PE_absptr.  I don't know if this is specified
>    anywhere.
>
>   All those workarounds (i.e. support for USE_EH_FRAME_HDR) will be
>   removed before the patch goes in and replaced by a check for a Sun ld
>   version without the bugs.
>
> * I'm using config/t-sol2-eh to set LIB2ADDEH and LIB2ADDEHDEP.  The
>   same snippet is used in three other places: config/{t-freebsd,
>   t-libunwind-elf, t-linux} and it might be useful to move this into a
>   separate file included everywhere.  Perhaps config/t-glibc-eh,
>   although this is a misnomer now that FreeBSD and Solaris libc also
>   provide dl_iterate_phdr.  t-dip-eh?
>
> * Along the same line, unwind-dw2-fde-glibc.c is misnamed, too.
>   Probably not worthwhile changing, though?
>
> * Until Solaris 11 build 154, <link.h> cannot be used with largefile
>   support.  This is tracked as
>
>   6997934	<link.h> cannot be used in largefile-aware program
>   http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6997934
>
>   and the workarounds can probably go before the final patch goes in.
>
> With the patch below, I've successfully bootstrapped mainline on both
> i386-pc-solaris2.11 and sparc-sun-solaris2.11 with Sun ld and CVS GNU
> ld.  There's only a single regression right now where a couple of objc
> tests fail with gld:
>
> +FAIL: objc.dg/lto/trivial-1 objc_lto_trivial-1_0.o-objc_lto_trivial-1_0.o link, -O0 -fwhopr -fgnu-runtime
> +UNRESOLVED: objc.dg/lto/trivial-1 objc_lto_trivial-1_0.o-objc_lto_trivial-1_0.o execute -O0 -fwhopr -fgnu-runtime
>
> /vol/gcc/bin/gld-2.20.51: objc-dg-lto-trivial-1-01: hidden symbol `__gcc_personality_v0' in /vol/gcc/obj/gcc-4.6.0-20101029/11-gcc-gas-gld-cvs/gcc/libgcc_eh.a(unwind-c.o) is referenced by DSO
> /vol/gcc/bin/gld-2.20.51: final link failed: Nonrepresentable section on output
>
> They seem ultimately to be due to a misconstructed libobjc.so.2:
>
> $ ldd -d libobjc.so.2
>         libc.so.1 =>     /lib/libc.so.1
>         symbol not found: __gcc_personality_v0          (../../../i386-pc-solari
> s2.11/libobjc/.libs/libobjc.so.2)
>         libm.so.2 =>     /lib/libm.so.2
>
> It seems that libobjc.so should be built with -shared-libgcc, but I'm
> still investigating.
>
> Given how localized and Solaris-specific this patch is, would an updated
> form be ok for mainline despite being in stage 3?

Apart from Joseph's comment about being careful to make the configure
check for dl_iterate_phdr target-specific, there have been no comments
whatsoever on the applicability of this patch and on the specific
questions raised above in almost two weeks:

	http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02770.html

Anyone care to comment now?

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University