linker eh_frame unwind [was: missing libffi.so master link]

[Riccardo Mottola]

Hi,

thank you, Dago.

I made some important discovery, more below. I think a test failing is 
the problem.

Dagobert Michelsen wrote:
> I committed an adjusted PATH during configure in r24719. However, the compilation
> still fails with
>
>> >libtool: link:/opt/csw/bin/gcc-4.9 -shared  -fPIC -DPIC -Wl,-z -Wl,text -Wl,-h -Wl,libffi.so.6 -o .libs/libffi.so.6.0.4  src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o src/x86/.libs/ffi.o src/x86/.libs/sysv.o   -L/opt/csw/lib/64  -O2 -m64 -march=opteron -m64 -march=opteron -m64 -march=opteron
>> >ld: fatal: file src/x86/.libs/unix64.o: section [5].eh_frame: section type is SHT_PROGBITS: expected SHT_AMD64_UNWIND
>> >collect2: error: ld returned 1 exit status
> Probably you need to dive deeper in ELF and linking.
I think the problem is that the test:
checking toolchain supports unwind section type... no
returns no and not yes.

In fact,  we have this in the code:
#ifdef __GNUC__
/* Only emit DWARF unwind info when building with the GNU toolchain.  */

#ifdef HAVE_AS_X86_64_UNWIND_SECTION_TYPE
         .section        .eh_frame,"a", at unwind
#else
         .section        .eh_frame,"a", at progbits
#endif

(only for GNUC, this is why this wasn't happening with previous suncc, I 
don't know why it does work on 32bit though).

I manually defined in i386-pc-solaris2.10/fficonfig.h 
HAVE_AS_X86_64_UNWIND_SECTION_TYPE to 1
An now build completes. Which makes sense: it is exactly the warning our 
linker is spitting out.

The question is now: why does the check fail? I did some search and 
found this:
https://github.com/atgreen/libffi/issues/42 "Ensure the whole toolchain 
supports unwind section type"

For your convenience, a quick link to the patch:
https://hg.mozilla.org/mozilla-central/diff/94dc6f0b5f8b/js/src/ctypes/libffi/configure.ac

The goal would be that both compiler and linker support the type. We 
should have this patch (our message says "toolchain")

Why does it fail? the check should return "yes", the test explicitly 
says linker. Could it be that a different linker is used? That our 
environment is not set up correctly? Linking is done with $CC, so it 
should be fine, shouldn't it?


Riccardo