public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <joseph@codesourcery.com>
To: <libc-ports@sourceware.org>
Subject: Add ARM-specific static-stubs.c
Date: Thu, 05 Jul 2012 22:29:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.1207052216280.13568@digraph.polyomino.org.uk> (raw)

While the ARM changes I included with my patch to avoid libgcc_s / 
libgcc_eh were sufficient to keep the ARM glibc build working in cases 
that had already worked without special hacks, it turns out they weren't 
quite sufficient to get the ARM build to start working when using a 
compiler without libgcc_s / libgcc_eh.

With such a compiler, some of the unwind functionality is present in 
libgcc.a (whereas with a compiler built with shared libgcc, it's separate 
in libgcc_s and libgcc_eh).  The copy of _Unwind_Resume from 
static-stubs.c is properly used in static links - but libgcc gets used 
before ARM's libgcc-stubs.a, so __aeabi_unwind_cpp_pr* get pulled in from 
libgcc, which ends up conflicting with the copy of _Unwind_Resume from 
static-stubs.c.  So in fact the stub __aeabi_unwind_cpp_pr* need providing 
in two places:

* In static-stubs.c (via a #include of aeabi_unwind_cpp_pr1.c), for static 
links with a compiler with libgcc.a only.

* In libgcc-stubs.a, for linking other executables and shared libraries.

I've applied this patch to get the ARM build working with a compiler with 
static-only libgcc, though I'll think some more about whether better 
approaches are possible.

diff --git a/ports/ChangeLog.arm b/ports/ChangeLog.arm
index 71e8b1b..8cd383d 100644
--- a/ports/ChangeLog.arm
+++ b/ports/ChangeLog.arm
@@ -1,3 +1,7 @@
+2012-07-05  Joseph Myers  <joseph@codesourcery.com>
+
+	* sysdeps/arm/static-stubs.c: New file.
+
 2012-07-03  Joseph Myers  <joseph@codesourcery.com>
 
 	* sysdeps/arm/Makefile (gnulib-arch): New variable.
diff --git a/ports/sysdeps/arm/static-stubs.c b/ports/sysdeps/arm/static-stubs.c
new file mode 100644
index 0000000..d90d603
--- /dev/null
+++ b/ports/sysdeps/arm/static-stubs.c
@@ -0,0 +1,7 @@
+/* When building with GCC with static-only libgcc, the dummy
+   _Unwind_Resume from static-stubs.c needs to be used together with
+   the dummy __aeabi_unwind_cpp_pr* from aeabi_unwind_cpp_pr1.c
+   instead of the copies from libgcc.  */
+
+#include <elf/static-stubs.c>
+#include <aeabi_unwind_cpp_pr1.c>

-- 
Joseph S. Myers
joseph@codesourcery.com

                 reply	other threads:[~2012-07-05 22:29 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=Pine.LNX.4.64.1207052216280.13568@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=libc-ports@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).