GCC Bugzilla – Full Text Bug Listing
|Summary:||libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc|
|Component:||target||Assignee:||Alan Modra <amodra>|
|Severity:||normal||CC:||bergner, compnerd, dje, gcc-bugs, ian, meissner, rhabarber1848, wd|
|Build:||x86_64-unknown-linux-gnu||Known to work:|
|Known to fail:||4.5.1||Last reconfirmed:||2010-08-11 07:30:59|
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