* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
@ 2009-09-09 18:29 David Edelsohn
0 siblings, 0 replies; 19+ messages in thread
From: David Edelsohn @ 2009-09-09 18:29 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Matthias Klose, Alexandre Oliva, Nathan Froyd, GCC Patches,
Paolo Carlini, GCJ-patches, Ralf Wildenhues
> If this patch is committed, I hope Nathan could commit his rs6000 fix as
> well (would it be acceptable to 4.4 as well)?
I am glad that we finally have some consensus on how to move forward.
The t-slibgcc scripts and Nathan's patch are fine with me for rs6000
on mainline and 4.4.
Thanks, David
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-09-09 11:24 ` Jakub Jelinek
2009-09-09 12:27 ` Joseph S. Myers
@ 2009-09-11 17:13 ` Matthias Klose
1 sibling, 0 replies; 19+ messages in thread
From: Matthias Klose @ 2009-09-11 17:13 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Alexandre Oliva, Nathan Froyd, GCC Patches, Paolo Carlini,
GCJ-patches, Ralf Wildenhues
[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]
On 09.09.2009 13:24, Jakub Jelinek wrote:
> On Mon, Jul 13, 2009 at 09:12:27AM -0400, Matthias Klose wrote:
>> this doesn't seem to work together with -nostdlib, e.g. how libstdc++ is linked
>> (libstdc++ ends up with undefined symbols from libgcc). Current libtool has it's
>> own idea about linking with libgcc, and doesn't link with -lgcc (explicitely
>> removing it from the command line if it's there). So do we have to change
>> libtool at the same time to support linking with both libgcc_s and libgcc?
>
> After discussing this with Alex on IRC today, we agreed that the linker
> script for targets that need it is probably easier.
>
> But, completely duplicating the SHLIB_LINK/SHLIB_INSTALL variables,
> especially without all the variables that can tweak it, is IMHO a wrong
> idea. We should avoid the duplication.
>
> The following patch has been tested on powerpc64-linux --with-cpu=default32
> together with a
> --- rs6000.c.jj 2009-09-04 16:42:37.465404822 +0200
> +++ rs6000.c 2009-09-09 12:15:01.502404904 +0200
> @@ -18011,7 +18011,7 @@ static bool
> no_global_regs_above (int first, bool gpr)
> {
> int i;
> - for (i = first; i< gpr ? 32 : 64 ; i++)
> + for (i = first; i< (gpr ? 32 : 64) ; i++)
> if (global_regs[i])
> return false;
> return true;
> fix (I know Nathan has a more complete patch). arm*-*-linux* could add the
> same into config.gcc, similarly sh*-*-linux* (you said sh uses it already,
> but I couldn't find anything like that in config/sh/t-*).
>
> If this patch is committed, I hope Nathan could commit his rs6000 fix as
> well (would it be acceptable to 4.4 as well)?
>
> 2009-09-09 Jakub Jelinek<jakub@redhat.com>
>
> * config/t-slibgcc-elf-ver (SHLIB_MAKE_SOLINK, SHLIB_INSTALL_SOLINK):
> New variables.
> (SHLIB_LINK, SHLIB_INSTALL): Use them.
> * config/t-slibgcc-libgcc: New file.
> * config.gcc (powerpc*-*-linux*, powerpc*-*-gnu*): Use it.
Applied and checked the attach patch on top of your patch, ran the testsuite
without regressions (applied the patch for pr40133 from Paolo for the same test
run as well).
Matthias
[-- Attachment #2: arm.diff --]
[-- Type: text/plain, Size: 523 bytes --]
Index: gcc/config.gcc
===================================================================
--- a/src/gcc/config.gcc (revision 151558)
+++ b/src/gcc/config.gcc (working copy)
@@ -727,7 +727,7 @@
;;
esac
tm_file="$tm_file arm/aout.h arm/arm.h"
- tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
+ tmake_file="${tmake_file} t-slibgcc-libgcc arm/t-arm-softfp soft-fp/t-softfp"
;;
arm*-*-uclinux*) # ARM ucLinux
tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h arm/uclinux-elf.h"
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-09-09 19:50 ` Richard Henderson
@ 2009-09-09 20:56 ` Joseph S. Myers
0 siblings, 0 replies; 19+ messages in thread
From: Joseph S. Myers @ 2009-09-09 20:56 UTC (permalink / raw)
To: Richard Henderson
Cc: Jakub Jelinek, Matthias Klose, Alexandre Oliva, Nathan Froyd,
GCC Patches, Paolo Carlini, GCJ-patches, Ralf Wildenhues
On Wed, 9 Sep 2009, Richard Henderson wrote:
> On 09/09/2009 06:25 AM, Jakub Jelinek wrote:
> > Thanks. Anyway, this new t-slibgcc-libgcc has to be either in gcc/config/
> > together with t-slibgcc-elf-ver, or t-slibgcc-elf-ver would need to be moved
> > over to libgcc/config too (as variable references are resolved at
> > libgcc.mvars creation time).
>
> Personally, I'm all for moving everything that can be
> moved to the libgcc subdir.
So am I, but a lot of the settings are heavily entangled with each other
and so need migrating at once and it's very fiddly to make sure no
settings are accidentally changed for every target.
I think <http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration> is still
essentially current, as far as it goes; most of the startfiles migration
described there has yet to happen for most targets.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-09-09 13:25 ` Jakub Jelinek
@ 2009-09-09 19:50 ` Richard Henderson
2009-09-09 20:56 ` Joseph S. Myers
0 siblings, 1 reply; 19+ messages in thread
From: Richard Henderson @ 2009-09-09 19:50 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Joseph S. Myers, Matthias Klose, Alexandre Oliva, Nathan Froyd,
GCC Patches, Paolo Carlini, GCJ-patches, Ralf Wildenhues
On 09/09/2009 06:25 AM, Jakub Jelinek wrote:
> Thanks. Anyway, this new t-slibgcc-libgcc has to be either in gcc/config/
> together with t-slibgcc-elf-ver, or t-slibgcc-elf-ver would need to be moved
> over to libgcc/config too (as variable references are resolved at
> libgcc.mvars creation time).
Personally, I'm all for moving everything that can be
moved to the libgcc subdir.
r~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-09-09 12:27 ` Joseph S. Myers
@ 2009-09-09 13:25 ` Jakub Jelinek
2009-09-09 19:50 ` Richard Henderson
0 siblings, 1 reply; 19+ messages in thread
From: Jakub Jelinek @ 2009-09-09 13:25 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Matthias Klose, Alexandre Oliva, Nathan Froyd, GCC Patches,
Paolo Carlini, GCJ-patches, Ralf Wildenhues
On Wed, Sep 09, 2009 at 12:27:48PM +0000, Joseph S. Myers wrote:
> On Wed, 9 Sep 2009, Jakub Jelinek wrote:
>
> > same into config.gcc, similarly sh*-*-linux* (you said sh uses it already,
> > but I couldn't find anything like that in config/sh/t-*).
>
> It's in libgcc/config/sh/t-linux.
Thanks. Anyway, this new t-slibgcc-libgcc has to be either in gcc/config/
together with t-slibgcc-elf-ver, or t-slibgcc-elf-ver would need to be moved
over to libgcc/config too (as variable references are resolved at
libgcc.mvars creation time).
Jakub
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-09-09 11:24 ` Jakub Jelinek
@ 2009-09-09 12:27 ` Joseph S. Myers
2009-09-09 13:25 ` Jakub Jelinek
2009-09-11 17:13 ` Matthias Klose
1 sibling, 1 reply; 19+ messages in thread
From: Joseph S. Myers @ 2009-09-09 12:27 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Matthias Klose, Alexandre Oliva, Nathan Froyd, GCC Patches,
Paolo Carlini, GCJ-patches, Ralf Wildenhues
On Wed, 9 Sep 2009, Jakub Jelinek wrote:
> same into config.gcc, similarly sh*-*-linux* (you said sh uses it already,
> but I couldn't find anything like that in config/sh/t-*).
It's in libgcc/config/sh/t-linux.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-13 13:43 ` Matthias Klose
@ 2009-09-09 11:24 ` Jakub Jelinek
2009-09-09 12:27 ` Joseph S. Myers
2009-09-11 17:13 ` Matthias Klose
0 siblings, 2 replies; 19+ messages in thread
From: Jakub Jelinek @ 2009-09-09 11:24 UTC (permalink / raw)
To: Matthias Klose, Alexandre Oliva, Nathan Froyd
Cc: GCC Patches, Paolo Carlini, GCJ-patches, Ralf Wildenhues
On Mon, Jul 13, 2009 at 09:12:27AM -0400, Matthias Klose wrote:
> this doesn't seem to work together with -nostdlib, e.g. how libstdc++ is linked
> (libstdc++ ends up with undefined symbols from libgcc). Current libtool has it's
> own idea about linking with libgcc, and doesn't link with -lgcc (explicitely
> removing it from the command line if it's there). So do we have to change
> libtool at the same time to support linking with both libgcc_s and libgcc?
After discussing this with Alex on IRC today, we agreed that the linker
script for targets that need it is probably easier.
But, completely duplicating the SHLIB_LINK/SHLIB_INSTALL variables,
especially without all the variables that can tweak it, is IMHO a wrong
idea. We should avoid the duplication.
The following patch has been tested on powerpc64-linux --with-cpu=default32
together with a
--- rs6000.c.jj 2009-09-04 16:42:37.465404822 +0200
+++ rs6000.c 2009-09-09 12:15:01.502404904 +0200
@@ -18011,7 +18011,7 @@ static bool
no_global_regs_above (int first, bool gpr)
{
int i;
- for (i = first; i < gpr ? 32 : 64 ; i++)
+ for (i = first; i < (gpr ? 32 : 64) ; i++)
if (global_regs[i])
return false;
return true;
fix (I know Nathan has a more complete patch). arm*-*-linux* could add the
same into config.gcc, similarly sh*-*-linux* (you said sh uses it already,
but I couldn't find anything like that in config/sh/t-*).
If this patch is committed, I hope Nathan could commit his rs6000 fix as
well (would it be acceptable to 4.4 as well)?
2009-09-09 Jakub Jelinek <jakub@redhat.com>
* config/t-slibgcc-elf-ver (SHLIB_MAKE_SOLINK, SHLIB_INSTALL_SOLINK):
New variables.
(SHLIB_LINK, SHLIB_INSTALL): Use them.
* config/t-slibgcc-libgcc: New file.
* config.gcc (powerpc*-*-linux*, powerpc*-*-gnu*): Use it.
--- gcc/config/t-slibgcc-elf-ver.jj 2009-05-04 16:46:30.000000000 +0200
+++ gcc/config/t-slibgcc-elf-ver 2009-09-09 11:45:36.000000000 +0200
@@ -28,6 +28,9 @@ SHLIB_OBJS = @shlib_objs@
SHLIB_DIR = @multilib_dir@
SHLIB_SLIBDIR_QUAL = @shlib_slibdir_qual@
SHLIB_LC = -lc
+SHLIB_MAKE_SOLINK = $(LN_S) $(SHLIB_SONAME) $(SHLIB_DIR)/$(SHLIB_SOLINK)
+SHLIB_INSTALL_SOLINK = $(LN_S) $(SHLIB_SONAME) \
+ $$(DESTDIR)$$(slibdir)$(SHLIB_SLIBDIR_QUAL)/$(SHLIB_SOLINK)
SHLIB_LINK = $(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) -shared -nodefaultlibs \
-Wl,--soname=$(SHLIB_SONAME) \
@@ -40,7 +43,7 @@ SHLIB_LINK = $(GCC_FOR_TARGET) $(LIBGCC2
$(SHLIB_DIR)/$(SHLIB_SONAME).backup; \
else true; fi && \
mv $(SHLIB_DIR)/$(SHLIB_SONAME).tmp $(SHLIB_DIR)/$(SHLIB_SONAME) && \
- $(LN_S) $(SHLIB_SONAME) $(SHLIB_DIR)/$(SHLIB_SOLINK)
+ $(SHLIB_MAKE_SOLINK)
# $(slibdir) double quoted to protect it from expansion while building
# libgcc.mk. We want this delayed until actual install time.
SHLIB_INSTALL = \
@@ -48,7 +51,6 @@ SHLIB_INSTALL = \
$(INSTALL_DATA) $(SHLIB_DIR)/$(SHLIB_SONAME) \
$$(DESTDIR)$$(slibdir)$(SHLIB_SLIBDIR_QUAL)/$(SHLIB_SONAME); \
rm -f $$(DESTDIR)$$(slibdir)$(SHLIB_SLIBDIR_QUAL)/$(SHLIB_SOLINK); \
- $(LN_S) $(SHLIB_SONAME) \
- $$(DESTDIR)$$(slibdir)$(SHLIB_SLIBDIR_QUAL)/$(SHLIB_SOLINK)
+ $(SHLIB_INSTALL_SOLINK)
SHLIB_MKMAP = $(srcdir)/mkmap-symver.awk
SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver
--- gcc/config/t-slibgcc-libgcc.jj 2009-09-09 12:01:29.000000000 +0200
+++ gcc/config/t-slibgcc-libgcc 2009-09-09 11:54:46.000000000 +0200
@@ -0,0 +1,32 @@
+# Copyright (C) 2009 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# <http://www.gnu.org/licenses/>.
+
+# Instead of creating $(SHLIB_SOLINK) symlink create a GNU ld
+# linker script which sources in both $(SHLIB_SONAME) and libgcc.a.
+# This is needed on targets where libgcc.a contains routines that aren't in
+# $(SHLIB_SONAME) and are needed for shared libraries.
+
+SHLIB_MAKE_SOLINK = \
+ (echo "/* GNU ld script"; \
+ echo " Use the shared library, but some functions are only in"; \
+ echo " the static library. */"; \
+ echo "GROUP ( $(SHLIB_SONAME) libgcc.a )" \
+ ) > $(SHLIB_DIR)/$(SHLIB_SOLINK)
+SHLIB_INSTALL_SOLINK = \
+ $(INSTALL_DATA) $(SHLIB_DIR)/$(SHLIB_SOLINK) \
+ $$(DESTDIR)$$(slibdir)$(SHLIB_SLIBDIR_QUAL)/$(SHLIB_SOLINK)
--- gcc/config.gcc.jj 2009-09-03 09:59:40.000000000 +0200
+++ gcc/config.gcc 2009-09-09 12:03:28.000000000 +0200
@@ -1927,7 +1927,7 @@ powerpc-*-linux* | powerpc64-*-linux*)
tm_file="${tm_file} rs6000/linux.h glibc-stdint.h"
;;
esac
- tmake_file="${tmake_file} rs6000/t-fprules-softfp soft-fp/t-softfp"
+ tmake_file="${tmake_file} t-slibgcc-libgcc rs6000/t-fprules-softfp soft-fp/t-softfp"
case ${target} in
powerpc*-*-linux*altivec*)
tm_file="${tm_file} rs6000/linuxaltivec.h" ;;
@@ -1943,19 +1943,19 @@ powerpc-*-linux* | powerpc64-*-linux*)
powerpc64-*-gnu*)
tm_file="${tm_file} elfos.h svr4.h freebsd-spec.h gnu.h rs6000/sysv4.h rs6000/default64.h rs6000/linux64.h rs6000/gnu.h glibc-stdint.h"
extra_options="${extra_options} rs6000/sysv4.opt rs6000/linux64.opt"
- tmake_file="t-slibgcc-elf-ver t-gnu"
+ tmake_file="t-slibgcc-elf-ver t-slibgcc-libgcc t-gnu"
;;
powerpc-*-gnu-gnualtivec*)
tm_file="${cpu_type}/${cpu_type}.h elfos.h svr4.h freebsd-spec.h gnu.h rs6000/sysv4.h rs6000/linux.h rs6000/linuxaltivec.h rs6000/gnu.h glibc-stdint.h"
extra_options="${extra_options} rs6000/sysv4.opt"
- tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t-ppcos t-slibgcc-elf-ver t-gnu rs6000/t-ppccomm"
+ tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t-ppcos t-slibgcc-elf-ver t-slibgcc-libgcc t-gnu rs6000/t-ppccomm"
if test x$enable_threads = xyes; then
thread_file='posix'
fi
;;
powerpc-*-gnu*)
tm_file="${cpu_type}/${cpu_type}.h elfos.h svr4.h freebsd-spec.h gnu.h rs6000/sysv4.h rs6000/linux.h rs6000/gnu.h glibc-stdint.h"
- tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t-ppcos t-slibgcc-elf-ver t-gnu rs6000/t-ppccomm"
+ tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t-ppcos t-slibgcc-elf-ver t-slibgcc-libgcc t-gnu rs6000/t-ppccomm"
extra_options="${extra_options} rs6000/sysv4.opt"
if test x$enable_threads = xyes; then
thread_file='posix'
Jakub
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 9:56 ` Jakub Jelinek
` (2 preceding siblings ...)
2009-07-10 7:01 ` Matthias Klose
@ 2009-07-13 13:43 ` Matthias Klose
2009-09-09 11:24 ` Jakub Jelinek
3 siblings, 1 reply; 19+ messages in thread
From: Matthias Klose @ 2009-07-13 13:43 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Matthias Klose, GCC Patches, Paolo Carlini, GCJ-patches, Ralf Wildenhues
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.
this doesn't seem to work together with -nostdlib, e.g. how libstdc++ is linked
(libstdc++ ends up with undefined symbols from libgcc). Current libtool has it's
own idea about linking with libgcc, and doesn't link with -lgcc (explicitely
removing it from the command line if it's there). So do we have to change
libtool at the same time to support linking with both libgcc_s and libgcc?
Matthias
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-10 7:01 ` Matthias Klose
@ 2009-07-10 7:56 ` Jakub Jelinek
0 siblings, 0 replies; 19+ messages in thread
From: Jakub Jelinek @ 2009-07-10 7:56 UTC (permalink / raw)
To: Matthias Klose; +Cc: GCC Patches, Paolo Carlini, GCJ-patches
On Fri, Jul 10, 2009 at 08:01:45AM +0200, Matthias Klose wrote:
> 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
What are these #ifdefs good for?
Isn't the whole init_gcc_specs routine wrapped in
#if defined(ENABLE_SHARED_LIBGCC) && !defined(REAL_LIBGCC_SPEC)
?
> + "%{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));
Jakub
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 9:56 ` Jakub Jelinek
2009-07-07 11:51 ` Dave Korn
2009-07-07 13:22 ` Nathan Froyd
@ 2009-07-10 7:01 ` Matthias Klose
2009-07-10 7:56 ` Jakub Jelinek
2009-07-13 13:43 ` Matthias Klose
3 siblings, 1 reply; 19+ messages in thread
From: Matthias Klose @ 2009-07-10 7:01 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Matthias Klose, GCC Patches, Paolo Carlini, GCJ-patches
[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]
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
[-- Attachment #2: pr40134-2.diff --]
[-- Type: text/plain, Size: 626 bytes --]
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));
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 15:30 ` Dave Korn
@ 2009-07-07 15:53 ` H.J. Lu
0 siblings, 0 replies; 19+ messages in thread
From: H.J. Lu @ 2009-07-07 15:53 UTC (permalink / raw)
To: Dave Korn, rsa, Steven Munroe
Cc: Jakub Jelinek, Matthias Klose, GCC Patches, Paolo Carlini, GCJ-patches
On Tue, Jul 7, 2009 at 8:22 AM, Dave
Korn<dave.korn.cygwin@googlemail.com> wrote:
> H.J. Lu wrote:
>
>>
>> Don't both with DFP. There will be a separate libdfp and gcc will use it
>> when it is ready.
>
>
> Thanks! Can you point me at upstream? We'll need to arrange a cygwin
> distro package for it when it's available.
>
Ryan and Steve have more details on libdfp.
--
H.J.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 13:52 ` H.J. Lu
@ 2009-07-07 15:30 ` Dave Korn
2009-07-07 15:53 ` H.J. Lu
0 siblings, 1 reply; 19+ messages in thread
From: Dave Korn @ 2009-07-07 15:30 UTC (permalink / raw)
To: H.J. Lu
Cc: Dave Korn, Jakub Jelinek, Matthias Klose, GCC Patches,
Paolo Carlini, GCJ-patches
H.J. Lu wrote:
>
> Don't both with DFP. There will be a separate libdfp and gcc will use it
> when it is ready.
Thanks! Can you point me at upstream? We'll need to arrange a cygwin
distro package for it when it's available.
cheers,
DaveK
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 13:45 ` Dave Korn
@ 2009-07-07 13:52 ` H.J. Lu
2009-07-07 15:30 ` Dave Korn
0 siblings, 1 reply; 19+ messages in thread
From: H.J. Lu @ 2009-07-07 13:52 UTC (permalink / raw)
To: Dave Korn
Cc: Jakub Jelinek, Matthias Klose, GCC Patches, Paolo Carlini, GCJ-patches
On Tue, Jul 7, 2009 at 6:53 AM, Dave
Korn<dave.korn.cygwin@googlemail.com> wrote:
> Jakub Jelinek wrote:
>> On Tue, Jul 07, 2009 at 01:01:03PM +0100, Dave Korn wrote:
>>>> 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).
>>> Argh. We don't have DFP on cygwin yet but probably want to add support
>>> soon. What's the issue with this? Shouldn't those kind of simple maths
>>> routines be in the shared libgcc and linked from there anyway?
>>
>> Certainly not, it is huge and rarely used.
>> E.g. on i?86-linux, linking all of libgcc.a objects except bid*.o into a
>> shared library is ~ 80KB .text, .5 KB .rodata, with the dfp stuff also in
>> it is ~ 900KB of .text, ~ 1.9 MB .rodata. As libgcc_s is linked into a huge
>> number of apps, this would be certainly not acceptable.
>
> Wow, never realised it was so big. Putting it in its own .so certainly
> makes sense to me. (Reassured to know it's just the size, and not a
> correctness issue.)
>
Don't both with DFP. There will be a separate libdfp and gcc will use it
when it is ready.
--
H.J.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 12:21 ` Jakub Jelinek
@ 2009-07-07 13:45 ` Dave Korn
2009-07-07 13:52 ` H.J. Lu
0 siblings, 1 reply; 19+ messages in thread
From: Dave Korn @ 2009-07-07 13:45 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Dave Korn, Matthias Klose, GCC Patches, Paolo Carlini, GCJ-patches
Jakub Jelinek wrote:
> On Tue, Jul 07, 2009 at 01:01:03PM +0100, Dave Korn wrote:
>>> 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).
>> Argh. We don't have DFP on cygwin yet but probably want to add support
>> soon. What's the issue with this? Shouldn't those kind of simple maths
>> routines be in the shared libgcc and linked from there anyway?
>
> Certainly not, it is huge and rarely used.
> E.g. on i?86-linux, linking all of libgcc.a objects except bid*.o into a
> shared library is ~ 80KB .text, .5 KB .rodata, with the dfp stuff also in
> it is ~ 900KB of .text, ~ 1.9 MB .rodata. As libgcc_s is linked into a huge
> number of apps, this would be certainly not acceptable.
Wow, never realised it was so big. Putting it in its own .so certainly
makes sense to me. (Reassured to know it's just the size, and not a
correctness issue.)
cheers,
DaveK
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 9:56 ` Jakub Jelinek
2009-07-07 11:51 ` Dave Korn
@ 2009-07-07 13:22 ` Nathan Froyd
2009-07-10 7:01 ` Matthias Klose
2009-07-13 13:43 ` Matthias Klose
3 siblings, 0 replies; 19+ messages in thread
From: Nathan Froyd @ 2009-07-07 13:22 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Matthias Klose, GCC Patches, Paolo Carlini, GCJ-patches
On Tue, Jul 07, 2009 at 11:14:25AM +0200, Jakub Jelinek wrote:
> 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.
>
> 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.
The patch isn't needed for ppc64-linux, because the linker synthesizes
the necessary routines when necessary. The code for emitting out of
line saves/restores is actually broken at the moment, but the patch to
fix the brokenness can't be committed because of the above issue.
-Nathan
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 11:51 ` Dave Korn
@ 2009-07-07 12:21 ` Jakub Jelinek
2009-07-07 13:45 ` Dave Korn
0 siblings, 1 reply; 19+ messages in thread
From: Jakub Jelinek @ 2009-07-07 12:21 UTC (permalink / raw)
To: Dave Korn; +Cc: Matthias Klose, GCC Patches, Paolo Carlini, GCJ-patches
On Tue, Jul 07, 2009 at 01:01:03PM +0100, Dave Korn wrote:
> > 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).
>
> Argh. We don't have DFP on cygwin yet but probably want to add support
> soon. What's the issue with this? Shouldn't those kind of simple maths
> routines be in the shared libgcc and linked from there anyway?
Certainly not, it is huge and rarely used.
E.g. on i?86-linux, linking all of libgcc.a objects except bid*.o into a
shared library is ~ 80KB .text, .5 KB .rodata, with the dfp stuff also in
it is ~ 900KB of .text, ~ 1.9 MB .rodata. As libgcc_s is linked into a huge
number of apps, this would be certainly not acceptable.
Jakub
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 9:56 ` Jakub Jelinek
@ 2009-07-07 11:51 ` Dave Korn
2009-07-07 12:21 ` Jakub Jelinek
2009-07-07 13:22 ` Nathan Froyd
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Dave Korn @ 2009-07-07 11:51 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Matthias Klose, GCC Patches, Paolo Carlini, GCJ-patches
Jakub Jelinek wrote:
> 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);
We've been doing this in the cygwin port for some time by defining
SHARED_LIBGCC_SPEC in a tm.h file. It seems to work OK for us.
> Most of libgcc.a is sane and on targets with visibility support
> makes all symbols hidden anyway.
Please be careful to avoid any "all-the-world's-an-ELF"isms!
> 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).
Argh. We don't have DFP on cygwin yet but probably want to add support
soon. What's the issue with this? Shouldn't those kind of simple maths
routines be in the shared libgcc and linked from there anyway?
cheers,
DaveK
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
2009-07-07 9:10 Matthias Klose
@ 2009-07-07 9:56 ` Jakub Jelinek
2009-07-07 11:51 ` Dave Korn
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: Jakub Jelinek @ 2009-07-07 9:56 UTC (permalink / raw)
To: Matthias Klose; +Cc: GCC Patches, Paolo Carlini, GCJ-patches
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.
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).
Jakub
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
@ 2009-07-07 9:10 Matthias Klose
2009-07-07 9:56 ` Jakub Jelinek
0 siblings, 1 reply; 19+ messages in thread
From: Matthias Klose @ 2009-07-07 9:10 UTC (permalink / raw)
To: GCC Patches; +Cc: Paolo Carlini, GCJ-patches
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]
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)?
Matthias
[1] http://gcc.gnu.org/ml/gcc/2009-05/msg00035.html
[2] http://gcc.gnu.org/PR40651
[-- Attachment #2: libgcc.diff --]
[-- Type: text/plain, Size: 1972 bytes --]
2009-07-07 Matthias Klose <doko@ubuntu.com>
PR target/40134
* config/arm/t-linux: New.
* config.host (arm*-*-linux*): Add arm/t-linux to tmake_file.
Index: libgcc/config.host
===================================================================
--- libgcc/config.host (revision 149314)
+++ libgcc/config.host (working copy)
@@ -203,6 +203,7 @@
arm*-*-netbsd*)
;;
arm*-*-linux*) # ARM GNU/Linux with ELF
+ tmake_file="arm/t-linux"
;;
arm*-*-uclinux*) # ARM ucLinux
;;
Index: libgcc/config/arm/t-linux
===================================================================
--- libgcc/config/arm/t-linux (revision 0)
+++ libgcc/config/arm/t-linux (revision 0)
@@ -0,0 +1,26 @@
+# Override SHLIB_LINK and SHLIB_INSTALL to use linker script
+# libgcc_s.so.
+SHLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -shared -nodefaultlibs \
+ -Wl,--soname=@shlib_base_name@.so.1 \
+ -Wl,--version-script=@shlib_map_file@ \
+ -o @multilib_dir@/@shlib_base_name@.so.1.tmp @multilib_flags@ \
+ @shlib_objs@ -lc && \
+ rm -f @multilib_dir@/@shlib_base_name@.so && \
+ if [ -f @multilib_dir@/@shlib_base_name@.so.1 ]; then \
+ mv -f @multilib_dir@/@shlib_base_name@.so.1 \
+ @multilib_dir@/@shlib_base_name@.so.1.backup; \
+ else true; fi && \
+ mv @multilib_dir@/@shlib_base_name@.so.1.tmp \
+ @multilib_dir@/@shlib_base_name@.so.1 && \
+ (echo "/* GNU ld script"; \
+ echo " Use the shared library, but some functions are only in"; \
+ echo " the static library. */"; \
+ echo "GROUP ( @shlib_base_name@.so.1 libgcc.a )" \
+ ) > @multilib_dir@/@shlib_base_name@.so
+SHLIB_INSTALL = \
+ $(mkinstalldirs) $(DESTDIR)$(slibdir)@shlib_slibdir_qual@; \
+ $(INSTALL_DATA) @multilib_dir@/@shlib_base_name@.so.1 \
+ $(DESTDIR)$(slibdir)@shlib_slibdir_qual@/@shlib_base_name@.so.1; \
+ rm -f $(DESTDIR)$(slibdir)@shlib_slibdir_qual@/@shlib_base_name@.so; \
+ $(INSTALL_DATA) @multilib_dir@/@shlib_base_name@.so \
+ $(DESTDIR)$(slibdir)@shlib_slibdir_qual@/@shlib_base_name@.so
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2009-09-11 17:13 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-09 18:29 [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc David Edelsohn
-- strict thread matches above, loose matches on Subject: below --
2009-07-07 9:10 Matthias Klose
2009-07-07 9:56 ` Jakub Jelinek
2009-07-07 11:51 ` Dave Korn
2009-07-07 12:21 ` Jakub Jelinek
2009-07-07 13:45 ` Dave Korn
2009-07-07 13:52 ` H.J. Lu
2009-07-07 15:30 ` Dave Korn
2009-07-07 15:53 ` H.J. Lu
2009-07-07 13:22 ` Nathan Froyd
2009-07-10 7:01 ` Matthias Klose
2009-07-10 7:56 ` Jakub Jelinek
2009-07-13 13:43 ` Matthias Klose
2009-09-09 11:24 ` Jakub Jelinek
2009-09-09 12:27 ` Joseph S. Myers
2009-09-09 13:25 ` Jakub Jelinek
2009-09-09 19:50 ` Richard Henderson
2009-09-09 20:56 ` Joseph S. Myers
2009-09-11 17:13 ` Matthias Klose
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).