This bug may concern the gcc documentation on section usage only. Crosscompiling "Das U-Boot" with gcc 4.8.2 for powerpc with -fpic -mrelocatable, some addresses are put into a section .data.rel.ro.local, e.g. the address of "qwerty" from printf("%p\n", "qwerty"); There is no corresponding entry in the .fixup section. As "Das U-Boot" relocates itself to RAM using .got2/.got and .fixup sections only, how shall the section .data.rel.ro.local be handled? Currently it contains addresses only, but this may depend on the source code. I put .data.rel.ro.local into the GOT which solved my problem, but I'm not sure if this is the intention of the gcc developers. I've tried gcc 4.7.3 which put the address of "qwerty" into the GOT directly, i.e. there was no .data.rel.ro.local section and the string address was accessed with one redirection less. details: - gcc version: powerpc-softfloat-linux-gnuspe-gcc (Gentoo 4.8.2 p1.3r1, pie-0.5.8r1) 4.8.2 - gcc command line (some -I removed): -g -gdwarf-2 -Os -fpic -mrelocatable \ -meabi \ -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xef770000 \ -fno-builtin -ffreestanding \ -isystem /usr/lib/gcc/powerpc-softfloat-linux-gnuspe/4.8.1/include \ -nostdinc -pipe -DCONFIG_PPC -D__powerpc__ -ffixed-r2 -Wa,-me500 \ -msoft-float -mno-string -mspe=yes -mno-spe -Wall -Wstrict-prototypes \ -fno-stack-protector -Wno-format-nonliteral -Wno-format-security \ -fstack-usage"
There is a patch at http://patchwork.ozlabs.org/patch/342888/ to address this issue and I THINK it is included in gcc-4.9.3 However, when I build the test case I do not get any .fixup section I cross building from amd64 to ppc32 if that is important
Fixed on master with git commit 8e2a42caa / svn rev 223209. Fixed for gcc-4.9 with git commit 110222ca0 / svn rev 223714. Fixed for gcc-4.8 with git commit 071358356 / svn rev 223713. Oddly, not backported to gcc-5? Regarding the testcase, you won't get .fixup entries unless a section other than .got/.got2 is holding addresses, which makes it a rather poor test.
(In reply to Alan Modra from comment #2) > Fixed on master with git commit 8e2a42caa / svn rev 223209. > Fixed for gcc-4.9 with git commit 110222ca0 / svn rev 223714. > Fixed for gcc-4.8 with git commit 071358356 / svn rev 223713. > > Oddly, not backported to gcc-5? > > Regarding the testcase, you won't get .fixup entries unless a section other > than .got/.got2 is holding addresses, which makes it a rather poor test. Not sure I understand, you mean that the existing test is failing and so is my test? How would you suggest I amend the test case to really get a .fixup? The strange thing is that u-boot still fails with gcc 4.9.3 but disabling -fno-ira-hoist-pressure makes it work again. Maybe the fix is non functional in gcc 4.9.3?
I meant by my testcase comment that gcc/testsuite/gcc.target/powerpc/pr60158.c is a poor test because it does not seem to emit addresses to .data.rel.ro.local or any other non-got section, on gcc-4.9, gcc-5 or master. That means it isn't testing that .fixup is emitted for the failing case found with gcc-4.8.2. I haven't investigated what is needed to write a proper testcase, but from mailing list comments the trigger involves reload. That makes it extremely difficult to test. If u-boot is failing, do you have any evidence that the cause is lack of .fixup? ie. can you see addresses in non-got sections?
I am sure I saw .data.rel.ro.local section with a .4byte statement in it using -S Now I cannot repeat it. The only thing that has changed that I know is glibc 2.19 is no glibc 2.20 and binutils from 2.24 to 2.25.1 Maybe binutils version makes a difference? Don't have that handy anymore
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9 development. See corresponding mailing list threads[1,2,3] for details. [1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html [2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html [3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html
(In reply to Segher Boessenkool from comment #6) > The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9 > development. See corresponding mailing list threads[1,2,3] for details. > > [1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html > [2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html > [3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html This is not SPE specific. More like powerpc or gcc
It does not happen on any target currently, and it has never happened on non-SPE targets before.
(In reply to Segher Boessenkool from comment #8) > It does not happen on any target currently, and it has never happened > on non-SPE targets before. The main user, u-boot, added the workaround with -fno-ira-hoist-pressure to avoid the bug: arch/powerpc/config.mk: Pass -fno-ira-hoist-pressure when possible There are various toolchain issues that cause us to produce invalid binaries with certain gcc 4.8.x and 4.9.x versions when we don't pass this flag in. Tested-by: Joakim Tjernlund <joakim.tjernlund@transmode.se> Signed-off-by: Tom Rini <trini@konsulko.com> The bug is still there as far as I known, the one-line patch hasn't been applied I think.
To be clear, this is still a bug for powerpc(SPE or no SPE) and possibly any other arch using fixup tables like ppc. One can workaround this bug by using the -fno-ira-hoist-pressure, I am not sure why this option work and if there is a chance it will stop working in the future.
Do you have a reproducer you can share? I'll happily reopen the PR then, of course!
(In reply to Segher Boessenkool from comment #11) > Do you have a reproducer you can share? > > I'll happily reopen the PR then, of course! After 6 years, no I don't. You could use the test case included in the the patch I think.