Bug 45053

Summary: libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
Product: gcc Reporter: dv
Component: targetAssignee: Alan Modra <amodra>
Status: ASSIGNED ---    
Severity: normal CC: bergner, compnerd, dje, gcc-bugs, ian, meissner, rhabarber1848, wd
Priority: P3    
Version: 4.5.0   
Target Milestone: ---   
Host: x86_64-unknown-linux-gnu Target: powerpc-none-linux-gnu
Build: x86_64-unknown-linux-gnu Known to work:
Known to fail: 4.5.1 Last reconfirmed: 2010-08-11 07:30:59
Attachments: Fix

Description dv 2010-07-24 12:42:37 UTC
	[I know this is a duplicate of 43810, but the information there is
	partly misleading, so I decided to file a new report.]
	If GCC is configured for powerpc with --enable-target-optspace,
	libgcc_s objects get compiled with -Os, and this causes libgcc_s
	to contain undefined symbols _savegpr_* and _restgpr_*.
	This is probably due to this commit:
	http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151729
	(The use of those symbols might also depend on --with-float=soft,
	I didn't test with a different float option.)
	Those symbols _savegpr_* and _restgpr_* are defined in
	crtsavgpr_s.o and crtresgpr_s.o, respectively.  But those objects
	are not linked into libgcc_s.
	The problem also occurs with gcc-4.5.1-RC-20100722 and with
	gcc-4.4.4, if the patch for pr41175 is applied.

Environment:
System: Linux sonnet 2.6.24-28-generic #1 SMP Fri Jun 18 14:18:04 UTC 2010 x86_64 GNU/Linux


host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: powerpc-none-linux-gnu
configured with: /work2/build/cross-own/src/gcc-4.5.0/configure --target=powerpc-none-linux-gnu --prefix=/work2/build/cross-own/ppc-own-tmp --disable-threads --disable-nls --disable-multilib --disable-libgomp --disable-libssp --disable-libmudflap --enable-decimal-float=no --disable-libssp --enable-shared --enable-languages=c --enable-checking=yes --enable-symvers=gnu --enable-target-optspace --with-float=soft --with-local-prefix=/work2/build/cross-own/ppc-own/sys-root --with-build-sysroot=/work2/build/cross-own/ppc-own/sys-root --with-sysroot=/work2/build/cross-own/ppc-own/sys-root

How-To-Repeat:
	configure for powerpc and --enable-target-optspace (and possibly --with-float=soft)
Comment 1 dv 2010-07-24 12:42:37 UTC
Fix:
	The workaround is not to use --enable-target-optspace.
	The correct fix would be to link libgcc_s against crtsavgpr_s.o
	and crtresgpr_s.o, but I don't know the build system of GCC well
	enough to figure out how to do that.
Comment 2 Mikael Pettersson 2010-07-24 13:22:37 UTC
The build on some targets including powerpc is supposed to create libgcc_s.so as a linker script that inputs BOTH the real shared libgcc_s.so and the static libgcc.a, as some symbols are only defined in the static libgcc.  Please make sure that you're preserving this linker script when installing gcc.

If you want to backport PR41175 to 4.4 then you also need to backport config.gcc changes related to the powerpc linker script from r151568.

(ARM has the same issue.  No I'm not responsible for this misdesign.)
Comment 3 dv 2010-07-24 13:35:48 UTC
Subject: Re:  libgcc_s link command misses crtsavgpr_s
 and crtresgpr_s for powerpc

On 07/24/10 15:22, mikpe at it dot uu dot se wrote:
> ------- Comment #2 from mikpe at it dot uu dot se  2010-07-24 13:22 -------
> The build on some targets including powerpc is supposed to create libgcc_s.so
> as a linker script that inputs BOTH the real shared libgcc_s.so and the static
> libgcc.a, as some symbols are only defined in the static libgcc.  Please make
> sure that you're preserving this linker script when installing gcc.
> 
> If you want to backport PR41175 to 4.4 then you also need to backport
> config.gcc changes related to the powerpc linker script from r151568.
> 
> (ARM has the same issue.  No I'm not responsible for this misdesign.)
> 
> 
This is not an issue of the linker script, as the linker script
doesn't give a DSO (correctly) access to hidden symbols in another
library of the same group.
You relly need to link those objects into libgcc_s, as those symbols
aren't fit for calling through dynamic symbol lookup.

Comment 4 Mikael Pettersson 2010-07-24 19:36:40 UTC
Attempting to bootstrap 4.5.1-RC on powerpc-linux with --enable-target-optspace fails near the end of stage1 while configuring libgomp:

configure:3658: checking for C compiler default output file name
configure:3680: /home/mikpe/objdir/./gcc/xgcc -B/home/mikpe/objdir/./gcc/ -B/tmp/install/powerpc-unknown-linux-gnu/bin/ -B/tmp/install/powerpc-unknown-linux-gnu/lib/ -isystem /tmp/install/powerpc-unknown-linux-gnu/include -isystem /tmp/install/powerpc-unknown-linux-gnu/sys-include    -g -Os   conftest.c  >&5
/home/mikpe/objdir/./gcc/crtend.o: In function `__do_global_ctors_aux':
crtstuff.c:(.text+0xc): undefined reference to `_savegpr_31'
collect2: ld returned 1 exit status

libgcc.a was built and does define _savegpr_31, and libgcc_s.so is the expected linker script, and both files are available in the build directory.

So yes, --enable-target-optspace appears broken.
Comment 5 Paolo Carlini 2010-08-05 14:38:19 UTC
Ian, is this a libgcc issue? Can you suggest the best wa to triage it? Thanks.
Comment 6 Ian Lance Taylor 2010-08-11 04:28:49 UTC
Yes, this is a libgcc issue.  This kind of target-specific issue is normally handled by the relevant backend maintainers.

I'm surprised that it doesn't work, as libgcc/config/rs6000/t-ppccomm includes crtsavgpr.S and crtresgpr.S in LIB2ADD_ST.  I would expect that to include the required functions.  But I haven't tried it, and apparently something goes wrong.
Comment 7 Paolo Carlini 2010-08-11 07:26:56 UTC
Thanks for your feedback Ian. Now, I'm not sure which target maintainer to suggest for powerpc-linux... David Edelsohn?
Comment 8 dv 2010-08-11 10:56:41 UTC
Subject: Re:  libgcc_s link command misses crtsavgpr_s
 and crtresgpr_s for powerpc

@Ian:
> I'm surprised that it doesn't work, as libgcc/config/rs6000/t-ppccomm includes
> crtsavgpr.S and crtresgpr.S in LIB2ADD_ST.  I would expect that to include the
> required functions.
Maybe the problem is that the functions are only referenced if you use
-Os.  So if there's some automatism going on that collects all the
required symbols, this automatism needs to use -Os for target-optspace.
But I have no real idea how the build process works, so this is just
guessing.

Comment 9 Richard Biener 2011-03-25 10:21:25 UTC
*** Bug 48278 has been marked as a duplicate of this bug. ***
Comment 10 rhabarber1848 2012-04-12 14:42:55 UTC
This bug is still present in 4.7.0.
Comment 11 rhabarber1848 2012-04-13 22:35:58 UTC
Using this patch solves the problem here:
https://dev.openwrt.org/browser/trunk/toolchain/gcc/patches/4.7.0/870-ppc_no_crtsavres.patch

# ./powerpc-tuxbox-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=./powerpc-tuxbox-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/root/tuxbox/work_eglibc_dbox2_26_470/image/cdk/libexec/gcc/powerpc-tuxbox-linux-gnu/4.7.0/lto-wrapper
Target: powerpc-tuxbox-linux-gnu
Configured with: ../gcc-4.7.0/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=powerpc-tuxbox-linux-gnu --prefix=/root/tuxbox/work_eglibc_dbox2_26_470/image/cdk --with-sysroot=/root/tuxbox/work_eglibc_dbox2_26_470/image/cdkroot --with-native-system-header-dir=/include --enable-languages=c,c++ --with-cpu=823 --with-float=soft --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --with-gmp=/root/tuxbox/work_eglibc_dbox2_26_470/image/cdk --with-mpfr=/root/tuxbox/work_eglibc_dbox2_26_470/image/cdk --with-ppl=/root/tuxbox/work_eglibc_dbox2_26_470/image/cdk --with-cloog=/root/tuxbox/work_eglibc_dbox2_26_470/image/cdk --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --enable-target-optspace --disable-nls --enable-clocale=generic --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-shared
Thread model: posix
gcc version 4.7.0 (GCC)
Comment 12 Alan Modra 2013-02-07 08:36:45 UTC
Some of the claims made in various comments are wrong, at least for current gcc-4.7 svn rev 195829.  Even the subject is wrong.  libgcc_s.so *is* linked with the crtsav/res objects.  They are contained in libgcc.a, and libgcc.a is used when linking libgcc_s.so.  I have verified that libgcc_s.so built with -Os due to --enable-target-optspace does need various _savegpr* and _restgpr* functions.

Comment #4 shows the real problem nicely.  Notice that the reference to _savegpr_31 comes from crtend.o which the penultimate object on the linker command line, *after* libgcc.a.  So if no other object linked needs the out-of-line register save functions they won't be extracted from libgcc.a.

$ nm crtbegin.o | grep gpr
         U _restgpr_29_x
$ nm crtend.o | grep gpr
         U _restgpr_31_x
         U _savegpr_31
Comment 13 Alan Modra 2013-02-07 08:40:15 UTC
Created attachment 29382 [details]
Fix