libffi/configure.ac does not correctly determine writable eh_frame

libffi/configure.ac does not correctly determine writable eh_frame

[Ian Lance Taylor]

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.

Ian

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

[Anthony Green]

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?

AG


>
> Ian

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

[Ian Lance Taylor]

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