From: Riccardo Mottola <riccardo.mottola@libero.it>
To: libffi-discuss@sourceware.org
Subject: bug in unwind check for 64bit
Date: Sun, 15 Mar 2015 22:10:00 -0000 [thread overview]
Message-ID: <5506034E.9070501@libero.it> (raw)
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
Hi,
the configure check for unwind
if test x$TARGET = xX86_64; then
AC_CACHE_CHECK([toolchain supports unwind section type],
libffi_cv_as_x86_64_unwind_section_type, [
cat > conftest1.s << EOF
.text
.globl foo
foo:
jmp bar
.section .eh_frame,"a",@unwind
bar:
EOF
cat > conftest2.c << EOF
extern void foo();
int main(){foo();}
EOF
libffi_cv_as_x86_64_unwind_section_type=no
# we ensure that we can compile _and_ link an assembly file
containing an @unwind section
# since the compiler can support it and not the linker (ie old
binutils)
if $CC -Wa,--fatal-warnings $CFLAGS -c conftest1.s > /dev/null
2>&1 && \
$CC conftest2.c conftest1.o > /dev/null 2>&1 ; then
libffi_cv_as_x86_64_unwind_section_type=yes
fi
])
if test "x$libffi_cv_as_x86_64_unwind_section_type" = xyes; then
AC_DEFINE(HAVE_AS_X86_64_UNWIND_SECTION_TYPE, 1,
[Define if your assembler supports unwind section
type.])
fi
fi
is broken, it returns negative even if the option is supported. This
makes 64bit build on x86 fail (e.g. on solaris 10 in 64 bit).
The problem is that in the linking stage the CFLAGS are not passed, thus
the first CC line generates a 64 bit object, but then linking is
attempted in 32bit, which fails. $CFLAGS are needed there too.
The small attached patch fixed this problem, it comes from opencsw, and
I am giving it back to upstream.
Thank you,
Riccardo
[-- Attachment #2: configure.ac.patch --]
[-- Type: text/x-patch, Size: 547 bytes --]
--- configure.ac.orig Sun Mar 15 21:45:29 2015
+++ configure.ac Sun Mar 15 21:59:45 2015
@@ -490,7 +490,7 @@
# we ensure that we can compile _and_ link an assembly file containing an @unwind section
# since the compiler can support it and not the linker (ie old binutils)
if $CC -Wa,--fatal-warnings $CFLAGS -c conftest1.s > /dev/null 2>&1 && \
- $CC conftest2.c conftest1.o > /dev/null 2>&1 ; then
+ $CC $CFLAGS conftest2.c conftest1.o > /dev/null 2>&1 ; then
libffi_cv_as_x86_64_unwind_section_type=yes
fi
])
reply other threads:[~2015-03-15 22:10 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5506034E.9070501@libero.it \
--to=riccardo.mottola@libero.it \
--cc=libffi-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).