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

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

[Matthias Klose]

[-- 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

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

[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

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

[Dave Korn]

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

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

[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

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

[Nathan Froyd]

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

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

[Dave Korn]

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

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

[H.J. Lu]

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.

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

[Dave Korn]

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

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

[H.J. Lu]

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.

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

[Matthias Klose]

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

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

[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

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

[Matthias Klose]

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

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

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

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

[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@codesourcery.com

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

[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

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

[Richard Henderson]

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~

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

[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@codesourcery.com

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

[Matthias Klose]

[-- 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"

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

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

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

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

[-- Attachment #2: pr40134.diff --]
[-- Type: text/plain, Size: 726 bytes --]

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

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

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

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

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

[Matthias Klose]

On 22.09.2009 17:56, Andrew Haley wrote:
> 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.

Without this patch, the build of libjava fails on arm*-*-linux-*eabi:

/usr/bin/ld: .libs/jv-convert: hidden symbol `__sync_synchronize' in 
/root/gcc/newgccsnapshot/gcc-snapshot-20090919/build/./gcc/libgcc.a(linux-atomic.o) 
is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[5]: *** [jv-convert] Error 1

Full buildlog at http://people.debian.org/~doko/tmp/snapshot.log.bz2

The reason for this is not linking the shared libgcj with -lgcc.

Am I allowed to check in this patch to fix the build failure, or do I have to 
wait for an approval of an ARM maintainer?

   Matthias

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

[Andrew Haley]

Matthias Klose wrote:
> On 22.09.2009 17:56, Andrew Haley wrote:
>> 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.
> 
> Without this patch, the build of libjava fails on arm*-*-linux-*eabi:
> 
> /usr/bin/ld: .libs/jv-convert: hidden symbol `__sync_synchronize' in
> /root/gcc/newgccsnapshot/gcc-snapshot-20090919/build/./gcc/libgcc.a(linux-atomic.o)
> is referenced by DSO
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make[5]: *** [jv-convert] Error 1
> 
> Full buildlog at http://people.debian.org/~doko/tmp/snapshot.log.bz2
> 
> The reason for this is not linking the shared libgcj with -lgcc.

I find this extremely surprising.  LDFLAGS are explicitly set to do
that when building libgcc.  I did this myself, and I'm pretty sure that
it works.

svn diff -r150701:150702

> Am I allowed to check in this patch to fix the build failure, or do I
> have to wait for an approval of an ARM maintainer?

I think you need an ARM maintainer, but I first want to know why your
build isn't linking with libgcc.

Andrew.

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

[Matthias Klose]

On 24.09.2009 10:42, Andrew Haley wrote:
> Matthias Klose wrote:
>> On 22.09.2009 17:56, Andrew Haley wrote:
>>> 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.
>>
>> Without this patch, the build of libjava fails on arm*-*-linux-*eabi:
>>
>> /usr/bin/ld: .libs/jv-convert: hidden symbol `__sync_synchronize' in
>> /root/gcc/newgccsnapshot/gcc-snapshot-20090919/build/./gcc/libgcc.a(linux-atomic.o)
>> is referenced by DSO
>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>> collect2: ld returned 1 exit status
>> make[5]: *** [jv-convert] Error 1
>>
>> Full buildlog at http://people.debian.org/~doko/tmp/snapshot.log.bz2
>>
>> The reason for this is not linking the shared libgcj with -lgcc.
>
> I find this extremely surprising.  LDFLAGS are explicitly set to do
> that when building libgcc.  I did this myself, and I'm pretty sure that
> it works.
>
> svn diff -r150701:150702

The setting of LDFLAGS to "-Wl,-lgcc" (working around libtool assumptions) in 
the Makefile gets overwritten to the empty value when called by the toplevel 
make, so this has no effect.  The intent to do this with a linker script was to 
have it done for every usage.

>> Am I allowed to check in this patch to fix the build failure, or do I
>> have to wait for an approval of an ARM maintainer?
>
> I think you need an ARM maintainer, but I first want to know why your
> build isn't linking with libgcc.

Ok, Richard is seems to be in vacation until early October.

   Matthias

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

[Andrew Haley]

Matthias Klose wrote:
> On 24.09.2009 10:42, Andrew Haley wrote:
>> Matthias Klose wrote:
>>> On 22.09.2009 17:56, Andrew Haley wrote:
>>>> 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.
>>>
>>> Without this patch, the build of libjava fails on arm*-*-linux-*eabi:
>>>
>>> /usr/bin/ld: .libs/jv-convert: hidden symbol `__sync_synchronize' in
>>> /root/gcc/newgccsnapshot/gcc-snapshot-20090919/build/./gcc/libgcc.a(linux-atomic.o)
>>>
>>> is referenced by DSO
>>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>>> collect2: ld returned 1 exit status
>>> make[5]: *** [jv-convert] Error 1
>>>
>>> Full buildlog at http://people.debian.org/~doko/tmp/snapshot.log.bz2
>>>
>>> The reason for this is not linking the shared libgcj with -lgcc.
>>
>> I find this extremely surprising.  LDFLAGS are explicitly set to do
>> that when building libgcc.  I did this myself, and I'm pretty sure that
>> it works.
>>
>> svn diff -r150701:150702
> 
> The setting of LDFLAGS to "-Wl,-lgcc" (working around libtool
> assumptions) in the Makefile gets overwritten to the empty value when
> called by the toplevel make, so this has no effect.  The intent to do
> this with a linker script was to have it done for every usage.

I agree that a linker script is a better idea, I just wanted to know why
my fix wasn't working.  Thanks for that.

>>> Am I allowed to check in this patch to fix the build failure, or do I
>>> have to wait for an approval of an ARM maintainer?
>>
>> I think you need an ARM maintainer, but I first want to know why your
>> build isn't linking with libgcc.
> 
> Ok, Richard is seems to be in vacation until early October.

Righto.

Andrew.

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

[Richard Earnshaw]

On Thu, 2009-09-24 at 11:40 +0100, Andrew Haley wrote:
> Matthias Klose wrote:
> > On 24.09.2009 10:42, Andrew Haley wrote:
> >> Matthias Klose wrote:
> >>> On 22.09.2009 17:56, Andrew Haley wrote:
> >>>> 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.
> >>>
> >>> Without this patch, the build of libjava fails on arm*-*-linux-*eabi:
> >>>
> >>> /usr/bin/ld: .libs/jv-convert: hidden symbol `__sync_synchronize' in
> >>> /root/gcc/newgccsnapshot/gcc-snapshot-20090919/build/./gcc/libgcc.a(linux-atomic.o)
> >>>
> >>> is referenced by DSO
> >>> /usr/bin/ld: final link failed: Nonrepresentable section on output
> >>> collect2: ld returned 1 exit status
> >>> make[5]: *** [jv-convert] Error 1
> >>>
> >>> Full buildlog at http://people.debian.org/~doko/tmp/snapshot.log.bz2
> >>>
> >>> The reason for this is not linking the shared libgcj with -lgcc.
> >>
> >> I find this extremely surprising.  LDFLAGS are explicitly set to do
> >> that when building libgcc.  I did this myself, and I'm pretty sure that
> >> it works.
> >>
> >> svn diff -r150701:150702
> > 
> > The setting of LDFLAGS to "-Wl,-lgcc" (working around libtool
> > assumptions) in the Makefile gets overwritten to the empty value when
> > called by the toplevel make, so this has no effect.  The intent to do
> > this with a linker script was to have it done for every usage.
> 
> I agree that a linker script is a better idea, I just wanted to know why
> my fix wasn't working.  Thanks for that.
> 
> >>> Am I allowed to check in this patch to fix the build failure, or do I
> >>> have to wait for an approval of an ARM maintainer?
> >>
> >> I think you need an ARM maintainer, but I first want to know why your
> >> build isn't linking with libgcc.
> > 
> > Ok, Richard is seems to be in vacation until early October.

This isn't really my area; so I'm happy to trust Andrew's judgement in
this case.

R.

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

[Matthias Klose]

On 14.10.2009 15:38, Richard Earnshaw wrote:
>
> On Thu, 2009-09-24 at 11:40 +0100, Andrew Haley wrote:
>> Matthias Klose wrote:
>>> On 24.09.2009 10:42, Andrew Haley wrote:
>>>> Matthias Klose wrote:
>>>>> On 22.09.2009 17:56, Andrew Haley wrote:
>>>>>> 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.
>>>>>
>>>>> Without this patch, the build of libjava fails on arm*-*-linux-*eabi:
>>>>>
>>>>> /usr/bin/ld: .libs/jv-convert: hidden symbol `__sync_synchronize' in
>>>>> /root/gcc/newgccsnapshot/gcc-snapshot-20090919/build/./gcc/libgcc.a(linux-atomic.o)
>>>>>
>>>>> is referenced by DSO
>>>>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>>>>> collect2: ld returned 1 exit status
>>>>> make[5]: *** [jv-convert] Error 1
>>>>>
>>>>> Full buildlog at http://people.debian.org/~doko/tmp/snapshot.log.bz2
>>>>>
>>>>> The reason for this is not linking the shared libgcj with -lgcc.
>>>>
>>>> I find this extremely surprising.  LDFLAGS are explicitly set to do
>>>> that when building libgcc.  I did this myself, and I'm pretty sure that
>>>> it works.
>>>>
>>>> svn diff -r150701:150702
>>>
>>> The setting of LDFLAGS to "-Wl,-lgcc" (working around libtool
>>> assumptions) in the Makefile gets overwritten to the empty value when
>>> called by the toplevel make, so this has no effect.  The intent to do
>>> this with a linker script was to have it done for every usage.
>>
>> I agree that a linker script is a better idea, I just wanted to know why
>> my fix wasn't working.  Thanks for that.
>>
>>>>> Am I allowed to check in this patch to fix the build failure, or do I
>>>>> have to wait for an approval of an ARM maintainer?
>>>>
>>>> I think you need an ARM maintainer, but I first want to know why your
>>>> build isn't linking with libgcc.
>>>
>>> Ok, Richard is seems to be in vacation until early October.
>
> This isn't really my area; but I'm happy to trust Andrew's judgement in
> this case.

I committed this to the trunk yesterday after confirmation from Andrew.

Paolo, is it ok to apply r147076 again to fix PR40133 ?

   Matthias

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

[Matthias Klose]

ping on reapplying r147076 again to fix PR40133

thanks, Matthias

On 21.10.2009 15:23, Matthias Klose wrote:
> On 14.10.2009 15:38, Richard Earnshaw wrote:
>>
>> On Thu, 2009-09-24 at 11:40 +0100, Andrew Haley wrote:
>>> Matthias Klose wrote:
>>>> On 24.09.2009 10:42, Andrew Haley wrote:
>>>>> Matthias Klose wrote:
>>>>>> On 22.09.2009 17:56, Andrew Haley wrote:
>>>>>>> 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.
>>>>>>
>>>>>> Without this patch, the build of libjava fails on arm*-*-linux-*eabi:
>>>>>>
>>>>>> /usr/bin/ld: .libs/jv-convert: hidden symbol `__sync_synchronize' in
>>>>>> /root/gcc/newgccsnapshot/gcc-snapshot-20090919/build/./gcc/libgcc.a(linux-atomic.o)
>>>>>>
>>>>>>
>>>>>> is referenced by DSO
>>>>>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>>>>>> collect2: ld returned 1 exit status
>>>>>> make[5]: *** [jv-convert] Error 1
>>>>>>
>>>>>> Full buildlog at http://people.debian.org/~doko/tmp/snapshot.log.bz2
>>>>>>
>>>>>> The reason for this is not linking the shared libgcj with -lgcc.
>>>>>
>>>>> I find this extremely surprising. LDFLAGS are explicitly set to do
>>>>> that when building libgcc. I did this myself, and I'm pretty sure that
>>>>> it works.
>>>>>
>>>>> svn diff -r150701:150702
>>>>
>>>> The setting of LDFLAGS to "-Wl,-lgcc" (working around libtool
>>>> assumptions) in the Makefile gets overwritten to the empty value when
>>>> called by the toplevel make, so this has no effect. The intent to do
>>>> this with a linker script was to have it done for every usage.
>>>
>>> I agree that a linker script is a better idea, I just wanted to know why
>>> my fix wasn't working. Thanks for that.
>>>
>>>>>> Am I allowed to check in this patch to fix the build failure, or do I
>>>>>> have to wait for an approval of an ARM maintainer?
>>>>>
>>>>> I think you need an ARM maintainer, but I first want to know why your
>>>>> build isn't linking with libgcc.
>>>>
>>>> Ok, Richard is seems to be in vacation until early October.
>>
>> This isn't really my area; but I'm happy to trust Andrew's judgement in
>> this case.
>
> I committed this to the trunk yesterday after confirmation from Andrew.
>
> Paolo, is it ok to apply r147076 again to fix PR40133 ?
>
> Matthias

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

[Paolo Carlini]

Matthias Klose wrote:
> ping on reapplying r147076 again to fix PR40133
Did somebody fully address Joseph' comments here

    http://gcc.gnu.org/ml/gcc/2009-05/msg00039.html

???

I don't think so. In other terms, I don't think the compiler now links
the static libgcc, there is a serious target-independent part, isn't
just about arm-linux...

Paolo.

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

[Matthias Klose]

On 30.10.2009 01:28, Paolo Carlini wrote:
> Matthias Klose wrote:
>> ping on reapplying r147076 again to fix PR40133
> Did somebody fully address Joseph' comments here
>
>      http://gcc.gnu.org/ml/gcc/2009-05/msg00039.html
>
> ???
>
> I don't think so. In other terms, I don't think the compiler now links
> the static libgcc, there is a serious target-independent part, isn't
> just about arm-linux...

I checked that it does (at least on arm-linux-genueabi). IIUC the schema to do 
so implemented by Jakub and Alexandre can be extendend to targets that need to 
link with libgcc as well. Currently it is used for powerpc-linux and 
arm-linux-gnueabi (and linux-sh using it's own variant). I would have to look up 
hppa again.

   Matthias

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

[Paolo Carlini]

Matthias Klose wrote:
> I checked that it does (at least on arm-linux-genueabi). IIUC the
> schema to do so implemented by Jakub and Alexandre can be extendend to
> targets that need to link with libgcc as well. Currently it is used
> for powerpc-linux and arm-linux-gnueabi (and linux-sh using it's own
> variant). I would have to look up hppa again.
Yes, my point is exactly that that kind of scheme (
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00324.html, or equivalent)
must be really adopted, fixing only arm-linux isn't enough. In other
terms, 40134 still blocks 40133, and we cannot fix the latter until the
former is really fully fixed for *all* the affected targets. By the way,
that's why, sorry, I disregarded your ping in the first place, I was
pretty sure it wasn't time yet...

Paolo.

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

[Matthias Klose]

On 02.11.2009 17:28, Paolo Carlini wrote:
> Matthias Klose wrote:
>> I checked that it does (at least on arm-linux-genueabi). IIUC the
>> schema to do so implemented by Jakub and Alexandre can be extendend to
>> targets that need to link with libgcc as well. Currently it is used
>> for powerpc-linux and arm-linux-gnueabi (and linux-sh using it's own
>> variant). I would have to look up hppa again.
> Yes, my point is exactly that that kind of scheme (
> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00324.html, or equivalent)
> must be really adopted, fixing only arm-linux isn't enough.

In http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00733.html I wrote that this 
scheme requires fixing libtool; I never got feedback from the libtool 
maintainers. In http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00592.html Jakub 
and Alexandre did "agree that the linker script for targets that need it is 
probably easier".

> In other
> terms, 40134 still blocks 40133, and we cannot fix the latter until the
> former is really fully fixed for *all* the affected targets. By the way,
> that's why, sorry, I disregarded your ping in the first place, I was
> pretty sure it wasn't time yet...

So it looks like 40134 is fixed at least for all *-linux targets (I accidentally 
dropped the patch for parisc, now testing again). How to proceed with this for 
linux targets?

   Matthias

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

[Paolo Carlini]

Matthias Klose wrote:
> In http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00733.html I wrote
> that this scheme requires fixing libtool; I never got feedback from
> the libtool maintainers. In
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00592.html Jakub and
> Alexandre did "agree that the linker script for targets that need it
> is probably easier".
I'm still not convinced that all the targets possibly affected have been
dealt with. But, I don't consider myself knowledgeable enough in this
area, I'd like to see some comments from, eg, Jakub and Joseph, before
going ahead with the libstdc++ changes for 40133.
>> In other
>> terms, 40134 still blocks 40133, and we cannot fix the latter until the
>> former is really fully fixed for *all* the affected targets. By the way,
>> that's why, sorry, I disregarded your ping in the first place, I was
>> pretty sure it wasn't time yet...
> So it looks like 40134 is fixed at least for all *-linux targets (I
> accidentally dropped the patch for parisc, now testing again). How to
> proceed with this for linux targets?
In your original message you mentioned sparc too. Is it now fine?
Anyway, the configure changes I prepared for 40133 aren't linux-specific
would run anywhere, as I said above I'd like to be reassured by Joseph
and/or Jakub that such kind of test is now safe to use everywhere as far
as the compiler proper bits are concerned.

Paolo.

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

[Ralf Wildenhues]

* Matthias Klose wrote on Thu, Nov 12, 2009 at 07:18:47PM CET:
> On 02.11.2009 17:28, Paolo Carlini wrote:
> >Matthias Klose wrote:
> >>I checked that it does (at least on arm-linux-genueabi). IIUC the
> >>schema to do so implemented by Jakub and Alexandre can be extendend to
> >>targets that need to link with libgcc as well. Currently it is used
> >>for powerpc-linux and arm-linux-gnueabi (and linux-sh using it's own
> >>variant). I would have to look up hppa again.
> >Yes, my point is exactly that that kind of scheme (
> >http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00324.html, or equivalent)
> >must be really adopted, fixing only arm-linux isn't enough.
> 
> In http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00733.html I wrote
> that this scheme requires fixing libtool; I never got feedback from
> the libtool maintainers.

What would you suggest as the algorithm to fix it in libtool?
Mind you, I've probably forgotten parts of this, so please bear
with me:

Should libtool always reorder -lgcc_s before -lgcc if it sees
(or is to emit) both?  On all systems?  If not, on which?
Which of the two should it reorder, and where, if the two do
not occur successively?  What if another library dependency
drags in one but not the other, and we already have seen one
or both?

FWIW, I never saw a workable approach fixing libtool only,
nor understood how libtool could be fixed consistently.

Thanks,
Ralf

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

[Paolo Carlini]

Ralf Wildenhues wrote:
> What would you suggest as the algorithm to fix it in libtool?
> Mind you, I've probably forgotten parts of this, so please bear
> with me:
>
> Should libtool always reorder -lgcc_s before -lgcc if it sees
> (or is to emit) both?  On all systems?  If not, on which?
> Which of the two should it reorder, and where, if the two do
> not occur successively?  What if another library dependency
> drags in one but not the other, and we already have seen one
> or both?
>
> FWIW, I never saw a workable approach fixing libtool only,
> nor understood how libtool could be fixed consistently.
>   
If you are confident that *all* the linux targets at the moment are
fine, you can as well hardcode in the library configure that knowledge
and skip running the configure test for those. However, if you want to
put in place the looser configure check, you must be 100% sure that it
also works correctly on anything != linux, and that means, per Joseph'
comments, making sure those generic compiler bits about linking the
static libgcc are properly implemented. Either of those is fine with me.

Paolo

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

[Matthias Klose]

On 12.11.2009 19:32, Paolo Carlini wrote:
> Matthias Klose wrote:
>> In http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00733.html I wrote
>> that this scheme requires fixing libtool; I never got feedback from
>> the libtool maintainers. In
>> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00592.html Jakub and
>> Alexandre did "agree that the linker script for targets that need it
>> is probably easier".
> I'm still not convinced that all the targets possibly affected have been
> dealt with.

I addressed linux targets having a Debian port is available. sh/sh4 should be 
fine as it did link with -lgcc_s -lgcc before. Didn't check m68k-linux.

> But, I don't consider myself knowledgeable enough in this
> area, I'd like to see some comments from, eg, Jakub and Joseph, before
> going ahead with the libstdc++ changes for 40133.
>>> In other
>>> terms, 40134 still blocks 40133, and we cannot fix the latter until the
>>> former is really fully fixed for *all* the affected targets. By the way,
>>> that's why, sorry, I disregarded your ping in the first place, I was
>>> pretty sure it wasn't time yet...
>> So it looks like 40134 is fixed at least for all *-linux targets (I
>> accidentally dropped the patch for parisc, now testing again). How to
>> proceed with this for linux targets?
> In your original message you mentioned sparc too. Is it now fine?

no, sparc-linux was not affected, parisc was, which is now fixed on trunk.

> Anyway, the configure changes I prepared for 40133 aren't linux-specific
> would run anywhere, as I said above I'd like to be reassured by Joseph
> and/or Jakub that such kind of test is now safe to use everywhere as far
> as the compiler proper bits are concerned.

would a patch acceptable to run these link tests on linux only?

   Matthias

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

[Paolo Carlini]

On 12/09/2009 11:42 AM, Matthias Klose wrote:
> would a patch acceptable to run these link tests on linux only?
Sure. If you can cook up something running only where it's safe to run
it (I think linux targets are all safe), fine with me!

Paolo.

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

[Paolo Carlini]

On 12/09/2009 11:42 AM, Matthias Klose wrote:
> would a patch acceptable to run these link tests on linux only?

Sure. If you can cook up something (e.g, a version of the configure code
I wrote at the time) running only where it's safe to run it (I think
linux targets are all safe), fine with me!

Paolo.

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

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On 09.12.2009 11:50, Paolo Carlini wrote:
> On 12/09/2009 11:42 AM, Matthias Klose wrote:
>> would a patch acceptable to run these link tests on linux only?
>
> Sure. If you can cook up something (e.g, a version of the configure code
> I wrote at the time) running only where it's safe to run it (I think
> linux targets are all safe), fine with me!

the attached patch enables the link tests on linux, kfreebsd, and hurd targets. 
checked with the (Debian) kfreebsd and hurd maintainers that this is the right 
thing to do (although there doesn't exist an active port of these on arm or 
hppa. tested on i486-linux-gnu, arm-linux-gnueabi and hppa-linux-gnu. ok for the 
trunk?

   Matthias


[-- Attachment #2: pr40133.diff --]
[-- Type: text/plain, Size: 7519 bytes --]

libstdc++-v3/
2009-12-09  Paolo Carlini  <paolo.carlini@oracle.com>
	    Matthias Klose  <doko@ubuntu.com>

	PR libstdc++/40133
	* acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): On *-*-linux*,
	*-*-kfreebsd*-gnu | *-*-gnu* targets do link tests when possible.
	* configure: Regenerate.

Index: libstdc++-v3/acinclude.m4
===================================================================
--- a/src/libstdc++-v3/acinclude.m4	(revision 155104)
+++ b/src/libstdc++-v3/acinclude.m4	(working copy)
@@ -2438,8 +2438,7 @@
 dnl that are used should be checked.
 dnl
 dnl Note:
-dnl libgomp and libgfortran do this with a link test, instead of an asm test.
-dnl see: CHECK_SYNC_FETCH_AND_ADD
+dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD.
 dnl
 dnl Defines:
 dnl  _GLIBCXX_ATOMIC_BUILTINS_1 
@@ -2451,12 +2450,120 @@
   AC_LANG_SAVE
   AC_LANG_CPLUSPLUS
   old_CXXFLAGS="$CXXFLAGS"
-  
+
+  # Do link tests if possible, instead asm tests, limited to some platforms
+  atomic_builtins_link_tests=no
+  if test x$gcc_no_link != xyes; then
+    # Can do link tests. Limit to some tested platforms
+    case "$host" in
+      *-*-linux* | *-*-kfreebsd*-gnu | *-*-gnu*)
+	atomic_builtins_link_tests=yes
+        ;;
+    esac
+  fi
+
+  if test x$atomic_builtins_link_tests = xyes; then
+
+  # Do link tests.
+
+  CXXFLAGS="$CXXFLAGS -fno-exceptions"
+
+  AC_MSG_CHECKING([for atomic builtins for bool])
+  AC_CACHE_VAL(glibcxx_cv_atomic_bool, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef bool atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_bool=yes],
+      [glibcxx_cv_atomic_bool=no])
+  ])    
+  if test $glibcxx_cv_atomic_bool = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
+      [Define if builtin atomic operations for bool are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_bool)
+
+  AC_MSG_CHECKING([for atomic builtins for short])
+  AC_CACHE_VAL(glibcxx_cv_atomic_short, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef short atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_short=yes],
+      [glibcxx_cv_atomic_short=no])
+  ])    
+  if test $glibcxx_cv_atomic_short = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
+      [Define if builtin atomic operations for short are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_short)
+
+  AC_MSG_CHECKING([for atomic builtins for int])
+  AC_CACHE_VAL(glibcxx_cv_atomic_int, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef int atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_int=yes],
+      [glibcxx_cv_atomic_int=no])
+  ])    
+  if test $glibcxx_cv_atomic_int = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
+      [Define if builtin atomic operations for int are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_int)
+
+  AC_MSG_CHECKING([for atomic builtins for long long])
+  AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef long long atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_long_long=yes],
+      [glibcxx_cv_atomic_long_long=no])
+  ])    
+  if test $glibcxx_cv_atomic_long_long = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
+      [Define if builtin atomic operations for long long are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
+
+  else
+
+  # Do asm tests.
+
   # Compile unoptimized.
   CXXFLAGS='-O0 -S'
 
-  # Fake what AC_TRY_COMPILE does, without linking as this is
-  # unnecessary for a builtins test.
+  # Fake what AC_TRY_COMPILE does.
 
     cat > conftest.$ac_ext << EOF
 [#]line __oline__ "configure"
@@ -2478,14 +2585,14 @@
     AC_MSG_CHECKING([for atomic builtins for bool])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinsb=no
+        glibcxx_cv_atomic_bool=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
       [Define if builtin atomic operations for bool are supported on this host.])
-        enable_atomic_builtinsb=yes
+        glibcxx_cv_atomic_bool=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinsb)
+    AC_MSG_RESULT($glibcxx_cv_atomic_bool)
     rm -f conftest*
 
     cat > conftest.$ac_ext << EOF
@@ -2508,14 +2615,14 @@
     AC_MSG_CHECKING([for atomic builtins for short])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinss=no
+        glibcxx_cv_atomic_short=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
       [Define if builtin atomic operations for short are supported on this host.])
-        enable_atomic_builtinss=yes
+        glibcxx_cv_atomic_short=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinss)
+    AC_MSG_RESULT($glibcxx_cv_atomic_short)
     rm -f conftest*
 
     cat > conftest.$ac_ext << EOF
@@ -2539,14 +2646,14 @@
     AC_MSG_CHECKING([for atomic builtins for int])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinsi=no
+        glibcxx_cv_atomic_int=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
         [Define if builtin atomic operations for int are supported on this host.])
-        enable_atomic_builtinsi=yes
+        glibcxx_cv_atomic_int=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinsi)
+    AC_MSG_RESULT($glibcxx_cv_atomic_int)
     rm -f conftest*
 
     cat > conftest.$ac_ext << EOF
@@ -2569,22 +2676,23 @@
     AC_MSG_CHECKING([for atomic builtins for long long])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinsll=no
+        glibcxx_cv_atomic_long_long=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
       [Define if builtin atomic operations for long long are supported on this host.])
-        enable_atomic_builtinsll=yes
+        glibcxx_cv_atomic_long_long=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinsll)
+    AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
     rm -f conftest*
 
+  fi
 
   CXXFLAGS="$old_CXXFLAGS"
   AC_LANG_RESTORE
 
   # Set atomicity_dir to builtins if either of above tests pass.
-  if test $enable_atomic_builtinsi = yes || test $enable_atomic_builtinsb = yes ; then
+  if test $glibcxx_cv_atomic_int = yes || test $glibcxx_cv_atomic_bool = yes ; then
     atomicity_dir=cpu/generic/atomicity_builtins
   fi
 

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

[Paolo Carlini]

On 12/11/2009 05:19 AM, Matthias Klose wrote:
> the attached patch enables the link tests on linux, kfreebsd, and hurd
> targets. checked with the (Debian) kfreebsd and hurd maintainers that
> this is the right thing to do (although there doesn't exist an active
> port of these on arm or hppa. tested on i486-linux-gnu,
> arm-linux-gnueabi and hppa-linux-gnu. ok for the trunk?
First, thanks Matthias for your patience on this issue.

The patch looks very nice to me, just wait one day or so for comments
and then go ahead, patch is approved for mainline.

If you want, I would suggest adding a one-line comment in the code, say,
after " # Do link tests if possible, instead asm tests, limited to some
platforms", mentioning the PRs, these thorny issues about libgcc...

Thanks again,
Paolo.

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

[Joseph S. Myers]

On Fri, 11 Dec 2009, Matthias Klose wrote:

> On 09.12.2009 11:50, Paolo Carlini wrote:
> > On 12/09/2009 11:42 AM, Matthias Klose wrote:
> > > would a patch acceptable to run these link tests on linux only?
> > 
> > Sure. If you can cook up something (e.g, a version of the configure code
> > I wrote at the time) running only where it's safe to run it (I think
> > linux targets are all safe), fine with me!
> 
> the attached patch enables the link tests on linux, kfreebsd, and hurd
> targets. checked with the (Debian) kfreebsd and hurd maintainers that this is

Link tests are also safe for libstdc++ to use for uclinux targets.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On 11.12.2009 10:57, Paolo Carlini wrote:
> On 12/11/2009 05:19 AM, Matthias Klose wrote:
>> the attached patch enables the link tests on linux, kfreebsd, and hurd
>> targets. checked with the (Debian) kfreebsd and hurd maintainers that
>> this is the right thing to do (although there doesn't exist an active
>> port of these on arm or hppa. tested on i486-linux-gnu,
>> arm-linux-gnueabi and hppa-linux-gnu. ok for the trunk?
> First, thanks Matthias for your patience on this issue.
>
> The patch looks very nice to me, just wait one day or so for comments
> and then go ahead, patch is approved for mainline.
>
> If you want, I would suggest adding a one-line comment in the code, say,
> after " # Do link tests if possible, instead asm tests, limited to some
> platforms", mentioning the PRs, these thorny issues about libgcc...

updated the comment, enabled link tests for *-*-uclinux* as suggested by Joseph, 
committed to trunk.

   Matthias

[-- Attachment #2: pr40133.diff --]
[-- Type: text/plain, Size: 7692 bytes --]

libstdc++-v3/

2009-12-11  Paolo Carlini  <paolo.carlini@oracle.com>
	    Matthias Klose  <doko@ubuntu.com>

	PR libstdc++/40133
	* acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): On *-*-linux*,
	*-*-uclinux*, *-*-kfreebsd*-gnu | *-*-gnu* targets do link tests when
	possible.
        * configure: Regenerate.

Index: libstdc++-v3/acinclude.m4
===================================================================
--- libstdc++-v3/acinclude.m4	(revision 155196)
+++ libstdc++-v3/acinclude.m4	(working copy)
@@ -2438,8 +2438,7 @@
 dnl that are used should be checked.
 dnl
 dnl Note:
-dnl libgomp and libgfortran do this with a link test, instead of an asm test.
-dnl see: CHECK_SYNC_FETCH_AND_ADD
+dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD.
 dnl
 dnl Defines:
 dnl  _GLIBCXX_ATOMIC_BUILTINS_1 
@@ -2451,12 +2450,122 @@
   AC_LANG_SAVE
   AC_LANG_CPLUSPLUS
   old_CXXFLAGS="$CXXFLAGS"
-  
+
+  # Do link tests if possible, instead asm tests, limited to some platforms
+  # see discussion in PR target/40134, PR libstdc++/40133 and the thread
+  # starting at http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00322.html
+  atomic_builtins_link_tests=no
+  if test x$gcc_no_link != xyes; then
+    # Can do link tests. Limit to some tested platforms
+    case "$host" in
+      *-*-linux* | *-*-uclinux* | *-*-kfreebsd*-gnu | *-*-gnu*)
+	atomic_builtins_link_tests=yes
+        ;;
+    esac
+  fi
+
+  if test x$atomic_builtins_link_tests = xyes; then
+
+  # Do link tests.
+
+  CXXFLAGS="$CXXFLAGS -fno-exceptions"
+
+  AC_MSG_CHECKING([for atomic builtins for bool])
+  AC_CACHE_VAL(glibcxx_cv_atomic_bool, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef bool atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_bool=yes],
+      [glibcxx_cv_atomic_bool=no])
+  ])    
+  if test $glibcxx_cv_atomic_bool = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
+      [Define if builtin atomic operations for bool are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_bool)
+
+  AC_MSG_CHECKING([for atomic builtins for short])
+  AC_CACHE_VAL(glibcxx_cv_atomic_short, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef short atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_short=yes],
+      [glibcxx_cv_atomic_short=no])
+  ])    
+  if test $glibcxx_cv_atomic_short = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
+      [Define if builtin atomic operations for short are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_short)
+
+  AC_MSG_CHECKING([for atomic builtins for int])
+  AC_CACHE_VAL(glibcxx_cv_atomic_int, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef int atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_int=yes],
+      [glibcxx_cv_atomic_int=no])
+  ])    
+  if test $glibcxx_cv_atomic_int = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
+      [Define if builtin atomic operations for int are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_int)
+
+  AC_MSG_CHECKING([for atomic builtins for long long])
+  AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef long long atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_long_long=yes],
+      [glibcxx_cv_atomic_long_long=no])
+  ])    
+  if test $glibcxx_cv_atomic_long_long = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
+      [Define if builtin atomic operations for long long are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
+
+  else
+
+  # Do asm tests.
+
   # Compile unoptimized.
   CXXFLAGS='-O0 -S'
 
-  # Fake what AC_TRY_COMPILE does, without linking as this is
-  # unnecessary for a builtins test.
+  # Fake what AC_TRY_COMPILE does.
 
     cat > conftest.$ac_ext << EOF
 [#]line __oline__ "configure"
@@ -2478,14 +2587,14 @@
     AC_MSG_CHECKING([for atomic builtins for bool])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinsb=no
+        glibcxx_cv_atomic_bool=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
       [Define if builtin atomic operations for bool are supported on this host.])
-        enable_atomic_builtinsb=yes
+        glibcxx_cv_atomic_bool=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinsb)
+    AC_MSG_RESULT($glibcxx_cv_atomic_bool)
     rm -f conftest*
 
     cat > conftest.$ac_ext << EOF
@@ -2508,14 +2617,14 @@
     AC_MSG_CHECKING([for atomic builtins for short])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinss=no
+        glibcxx_cv_atomic_short=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
       [Define if builtin atomic operations for short are supported on this host.])
-        enable_atomic_builtinss=yes
+        glibcxx_cv_atomic_short=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinss)
+    AC_MSG_RESULT($glibcxx_cv_atomic_short)
     rm -f conftest*
 
     cat > conftest.$ac_ext << EOF
@@ -2539,14 +2648,14 @@
     AC_MSG_CHECKING([for atomic builtins for int])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinsi=no
+        glibcxx_cv_atomic_int=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
         [Define if builtin atomic operations for int are supported on this host.])
-        enable_atomic_builtinsi=yes
+        glibcxx_cv_atomic_int=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinsi)
+    AC_MSG_RESULT($glibcxx_cv_atomic_int)
     rm -f conftest*
 
     cat > conftest.$ac_ext << EOF
@@ -2569,22 +2678,23 @@
     AC_MSG_CHECKING([for atomic builtins for long long])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinsll=no
+        glibcxx_cv_atomic_long_long=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
       [Define if builtin atomic operations for long long are supported on this host.])
-        enable_atomic_builtinsll=yes
+        glibcxx_cv_atomic_long_long=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinsll)
+    AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
     rm -f conftest*
 
+  fi
 
   CXXFLAGS="$old_CXXFLAGS"
   AC_LANG_RESTORE
 
   # Set atomicity_dir to builtins if either of above tests pass.
-  if test $enable_atomic_builtinsi = yes || test $enable_atomic_builtinsb = yes ; then
+  if test $glibcxx_cv_atomic_int = yes || test $glibcxx_cv_atomic_bool = yes ; then
     atomicity_dir=cpu/generic/atomicity_builtins
   fi
 

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

[David Edelsohn]

> 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