[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)
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.
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.)
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.
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.
Ian, is this a libgcc issue? Can you suggest the best wa to triage it? Thanks.
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.
Thanks for your feedback Ian. Now, I'm not sure which target maintainer to suggest for powerpc-linux... David Edelsohn?
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.
*** Bug 48278 has been marked as a duplicate of this bug. ***
This bug is still present in 4.7.0.
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)
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
Created attachment 29382 [details] Fix
(In reply to Alan Modra from comment #13) > Created attachment 29382 [details] > Fix Alan, did this make it upstream? Can this be closed?
(In reply to Bill Schmidt from comment #14) > (In reply to Alan Modra from comment #13) > > Created attachment 29382 [details] > > Fix > > Alan, did this make it upstream? Can this be closed? Looking at trunk, no, this change is not upstream yet.
The patch didn't get approved. Richi stuck his nose into the patch submission thread. Mike Stump supported my patch but David didn't.
Author: amodra Date: Fri Apr 7 01:30:43 2017 New Revision: 246749 URL: https://gcc.gnu.org/viewcvs?rev=246749&root=gcc&view=rev Log: [RS6000] Out-of-line register save functions can't be used from crtend.o PR target/45053 * config/rs6000/t-crtstuff (CRTSTUFF_T_CFLAGS): Add -O2. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/rs6000/t-crtstuff
Dear Sender, Thank you for your mail, but I will probably not be able to reply any time soon as I'm currently out of office. I will try to reply to your message as quickly as possible after I'm back in the office on Monday, April 24. In the mean time please feel free to contact Mr. Stefano Babic <sbabic@denx.de> for all technical topics, or Ms. Erika Unter <e.unter@denx.de> for training classes and all organisatorical questions. Best regards, Wolfgang Denk
Removing the autoreply email from CCs
Author: amodra Date: Fri Apr 7 02:18:34 2017 New Revision: 246750 URL: https://gcc.gnu.org/viewcvs?rev=246750&root=gcc&view=rev Log: [RS6000] Out-of-line register save functions can't be used from crtend.o PR target/45053 * config/rs6000/t-crtstuff (CRTSTUFF_T_CFLAGS): Add -O2. Modified: branches/gcc-6-branch/libgcc/ChangeLog branches/gcc-6-branch/libgcc/config/rs6000/t-crtstuff
Author: amodra Date: Fri Apr 7 02:19:19 2017 New Revision: 246751 URL: https://gcc.gnu.org/viewcvs?rev=246751&root=gcc&view=rev Log: [RS6000] Out-of-line register save functions can't be used from crtend.o PR target/45053 * config/rs6000/t-crtstuff (CRTSTUFF_T_CFLAGS): Add -O2. Modified: branches/gcc-5-branch/libgcc/ChangeLog branches/gcc-5-branch/libgcc/config/rs6000/t-crtstuff
Fix applied all active branches.