public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ro at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/59788] Mixing libc and libgcc_s unwinders on 64-bit Solaris 10+/x86 breaks EH Date: Wed, 15 Jan 2014 12:48:00 -0000 [thread overview] Message-ID: <bug-59788-4-ESTPy8p297@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-59788-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788 --- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> --- Created attachment 31843 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31843&action=edit initial patch The attached initial patch works fine and fixes the testcase from the PR, but is unacceptable as is. Initially, I attempted to force direct binding to the libgcc_s unwinder by linking with a special mapfile if linking with -lgcc_s. This doesn't work since libtool builds shared libraries with -shared -nostdlib, adding -lgcc_s itself. The second attempt (attached) instead uses that mapfile when -shared is passed. When libtool adds -lgcc_s -lc -lgcc_s itself, it usually `optimizes' this into -lc -lgcc_s. When direct binding is in effect due to the mapfile, we achieve exactly what this patch intends to avoid, namely binding to the partial unwinder in amd64 libc. This can be avoided by patching libtool to disable this optimization on *solaris2*, which this patch does. While this works fine for the gcc runtime libraries, as can be observed with elfdump -y, gcc 4.9 cannot be released with this patch included: even if the libtool (ltmain.sh actually) patch were accepted upstream, every package built with libtool will contain an old copy without that change, causing the breakage this patch is designed to avoid. While the optimization can be avoided by invoking libtool with --preserve-dup-deps, this seem unacceptable, as would requiring users to run libtoolize from a hypothetical new libtool release with the ltmain.sh patch.
next prev parent reply other threads:[~2014-01-15 12:48 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-01-13 14:15 [Bug target/59788] New: " ro at gcc dot gnu.org 2014-01-13 14:15 ` [Bug target/59788] " ro at gcc dot gnu.org 2014-01-15 12:48 ` ro at gcc dot gnu.org [this message] 2014-01-17 14:22 ` ro at gcc dot gnu.org 2014-02-04 9:32 ` ro at gcc dot gnu.org 2014-02-04 9:33 ` ro at gcc dot gnu.org
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=bug-59788-4-ESTPy8p297@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.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: linkBe 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).