Re: libffi/configure.ac does not correctly determine writable eh_frame

[Ian Lance Taylor <iant@google.com>]

Anthony Green <green@redhat.com> writes:

> Ian Lance Taylor <iant@google.com> writes:
>
>> In the version of libffi distributed with gcc, I see this in
>> configure.ac:
>>
>> 	echo 'extern void foo (void); void bar (void) { foo (); foo (); }' > conftest.c
>> 	if $CC $CFLAGS -S -fpic -fexceptions -o conftest.s conftest.c > /dev/null 2>&1; then
>> 	    if grep '.section.*eh_frame.*"a"' conftest.s > /dev/null; then
>> 		libffi_cv_ro_eh_frame=yes
>> 	    elif grep '.section.*eh_frame.*#alloc' conftest.c \
>> 		 | grep -v '#write' > /dev/null; then
>> 		libffi_cv_ro_eh_frame=yes
>> 	    fi
>> 	fi
>>
>> This does not work with current gcc.  When that code is compiled, no
>> .eh_frame section is generated.  Therefore the configure script assumes
>> that a writable .eh_frame section is appropriate, even when it is not.
>>
>> This was detected due to a bug in gold; see http://gcc.gnu.org/PR47248
>> for more details.  However, this issue in libffi should be fixed
>> independently of the gold bug fix.
>
> Thanks Ian.  Any suggestions on what do I need to do to now to force an
> .eh_frame section?

Sorry, when I wrote the above note I was confused.  The object file
actually will get a .eh_frame section, because of the use of
-fexceptions.  What it won't get is a reference to .eh_frame in the
assembler file.  That is because gcc now generates CFI directives when
possible.  What you need to do know is use the compiler option
-fno-dwarf2-cfi-asm.  That will tell gcc to not use CFI directives, and
to use the .section eh_frame syntax instead.  In the context of gcc
mainline, you can assume that the compiler supports -fno-dwarf2-cfi-asm,
but of course in a more general syntax you would need to first test
whether the compiler supports that option.

That said, it would be even better if libffi could convert to using CFI
directives itself, which will avoid the whole question of what flags to
use for .eh_frame.  But I have to admit that I don't know all the
portability considerations that arise, nor do I know how portable libffi
is intended to be, nor do I know how critical it is to libffi operation
for exceptions to be handled correctly.  I note that
libffi/src/m68k/sysv.S is already using CFI directives.

Ian