This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
- From: Matthias Klose <doko at ubuntu dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Matthias Klose <doko at ubuntu dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Paolo Carlini <paolo dot carlini at oracle dot com>, GCJ-patches <java-patches at gcc dot gnu dot org>
- Date: Fri, 10 Jul 2009 08:01:45 +0200
- Subject: Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
- References: <4A530F5C.4040500@ubuntu.com> <20090707091425.GB4462@tyan-ft48-01.lab.bos.redhat.com>
Jakub Jelinek schrieb:
> On Tue, Jul 07, 2009 at 11:03:24AM +0200, Matthias Klose wrote:
>> Use a linker script to link with -lgcc_s -lgcc on arm-linux, which allows the
>> arm-linux target to run the testsuite without regressions with the patch for the
>> exception propagation support [1] enabled.
>>
>> The approach taken is the same as used on the sh-linux configuration.
>>
>> Tested on the 4.4 branch without regressions (c, c++, fortran, objc, obj-c++),
>> the trunk currently fails to build for unrelated reasons [2]
>>
>> Ok for the branch (and for the trunk after it bootstraps again)?
>
> For branch I think this could be acceptable, but for trunk I really think
> we should do this on all architectures that have shared libgcc_s*.
> It is not just arm/sh that need this, but also e.g. ppc-linux (and maybe
> ppc64-linux), where libgcc.a only contains the out of line gpr/fpr register
> save/restores.
>
> Something like (untested):
>
> --- gcc.c 2009-06-11 13:24:15.000000000 +0200
> +++ gcc.c 2009-07-07 11:11:27.664079777 +0200
> @@ -1733,11 +1733,11 @@ init_gcc_specs (struct obstack *obstack,
> "}"
> #ifdef LINK_EH_SPEC
> "%{shared:"
> - "%{shared-libgcc:", shared_name, "}"
> + "%{shared-libgcc:", shared_name, " ", static_name, "}"
> "%{!shared-libgcc:", static_name, "}"
> "}"
> #else
> - "%{shared:", shared_name, "}"
> + "%{shared:", shared_name, " ", static_name, "}"
> #endif
> #endif
> "}}", NULL);
>
> Most of libgcc.a is sane and on targets with visibility support
> makes all symbols hidden anyway.
I've tested the attached patch without regressions on arm-linux-gnueabi,
currently running tests on ix86 and powerpc.
> The major exception here are the dfp bits, here I'd think we should remove
> them from libgcc.a and put into libgcc_dfp.a or something similar
> (and have libgcc_dfp.so too).
H.J. mentioned not to bother with the dfp library for now. Is the current patch
good enough for mainline?
Matthias
Index: gcc.c
===================================================================
--- a/src/gcc/gcc.c (revision 149315)
+++ b/src/gcc/gcc.c (working copy)
@@ -1686,13 +1686,21 @@
"}"
#ifdef LINK_EH_SPEC
"%{shared:"
+#ifdef ENABLE_SHARED_LIBGCC
+ "%{shared-libgcc:", shared_name, " ", static_name, "}"
+#else
"%{shared-libgcc:", shared_name, "}"
+#endif
"%{!shared-libgcc:", static_name, "}"
"}"
#else
+#ifdef ENABLE_SHARED_LIBGCC
+ "%{shared:", shared_name, " ", static_name, "}"
+#else
"%{shared:", shared_name, "}"
#endif
#endif
+#endif
"}}", NULL);
obstack_grow (obstack, buf, strlen (buf));