[patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc

[Matthias Klose-6]

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

2009-07-07  Matthias Klose  <doko@...>

        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@... \
+ -Wl,--version-script=@shlib_map_file@ \
+ -o @multilib_dir@/@shlib_base_name@... @multilib_flags@ \
+ @shlib_objs@ -lc && \
+ rm -f @multilib_dir@/@shlib_base_name@.so && \
+ if [ -f @multilib_dir@/@shlib_base_name@... ]; then \
+  mv -f @multilib_dir@/@shlib_base_name@... \
+ @multilib_dir@/@shlib_base_name@...; \
+ else true; fi && \
+ mv @multilib_dir@/@shlib_base_name@... \
+   @multilib_dir@/@shlib_base_name@... && \
+ (echo "/* GNU ld script"; \
+ echo "   Use the shared library, but some functions are only in"; \
+ echo "   the static library.  */"; \
+ echo "GROUP ( @shlib_base_name@... libgcc.a )" \
+ ) > @multilib_dir@/@shlib_base_name@.so
+SHLIB_INSTALL = \
+ $(mkinstalldirs) $(DESTDIR)$(slibdir)@shlib_slibdir_qual@; \
+ $(INSTALL_DATA) @multilib_dir@/@shlib_base_name@... \
+  $(DESTDIR)$(slibdir)@shlib_slibdir_qual@/@shlib_base_name@...; \
+ 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

[Jakub Jelinek]

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

[Dave Korn-6]

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

[Jakub Jelinek]

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

[Nathan Froyd-2]

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

[Dave Korn-6]

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

[H.J. Lu-30]

On Tue, Jul 7, 2009 at 6:53 AM, Dave
Korn<dave.korn.cygwin@...> 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.

[Dave Korn-6]

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

[H.J. Lu-30]

On Tue, Jul 7, 2009 at 8:22 AM, Dave
Korn<dave.korn.cygwin@...> 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.

[Matthias Klose-6]

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));

[Jakub Jelinek]

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

[Matthias Klose-6]

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

[Jakub Jelinek]

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@...>

        * 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

[Joseph S. Myers]

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@...

[Jakub Jelinek]

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

[Richard Henderson-2]

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~

[Joseph S. Myers]

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@...

[Matthias Klose-6]

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@...>
>
> * 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

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"

[Matthias Klose-6]

On 11.09.2009 19:12, Matthias Klose wrote:

> 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@...>
>>
>> * 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

updated the patch to only for arm*-*-linux-*eabi; test results at
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02000.html

Ok for the trunk?

After that the reverted patch for pr40133 can be checked in.

   Matthias

2009-09-20  Matthias Klose  <doko@...>

        * config.gcc (arm*-*-linux-*eabi): Use config/t-slibgcc-libgcc.

Index: gcc/config.gcc
===================================================================
--- a/src/gcc/config.gcc (revision 151905)
+++ b/src/gcc/config.gcc (working copy)
@@ -719,7 +719,7 @@
  case ${target} in
  arm*-*-linux-*eabi)
     tm_file="$tm_file arm/bpabi.h arm/linux-eabi.h"
-    tmake_file="$tmake_file arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi"
+    tmake_file="$tmake_file arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi t-slibgcc-libgcc"
       # The BPABI long long divmod functions return a 128-bit value in
     # registers r0-r3.  Correctly modeling that requires the use of
     # TImode.

[Andrew Haley]

Matthias Klose wrote:
> On 11.09.2009 19:12, Matthias Klose wrote:

>> 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
>
> updated the patch to only for arm*-*-linux-*eabi; test results at
> http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02000.html
>
> Ok for the trunk?

I'm not at all happy that backtraces are failing now on Java, but I guess your
patch didn't cause that.  OK by me.

Andrew.