gcc.dg/split-1.exe and other split-stack executables broke recently on powerpc64le-linux, most likely due to git commit 6fbec038f7a7. I see [22] .init_array INIT_ARRAY 000000001001fda8 00fda8 000008 08 WAo 0 0 8 [23] .init_array INIT_ARRAY 000000001001fdb0 00fdb0 000010 00 WA 0 0 8 and in dynamic tags 0x0000000000000019 (INIT_ARRAY) 0x1001fda8 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) 0x0000000000000019 (INIT_ARRAY) 0x1001fdb0 0x000000000000001b (INIT_ARRAYSZ) 16 (bytes) ld.so won't handle multiple tags like this, and symbols __init_array_start and __init_array_end are defined to cover just the first .init_array section. The same thing happens on x86_64 when using gold, objects like crtbegin.o that have .init_array with "WAR" flags create separate .init_array output sections if being linked with glibc files containing .init_array without the "R" flag.
Moved.
When the gold patch goes in, gcc should have a configure test such that the combination of gold being the default linker and SHF_GNU_RETAIN support should not be allowed unless gold has the patch. And even if gold is not the default linker it is required for split-stack go support, so go being compiled also ought to trigger a dependence on gold being recent enough.
Jozef, SHF_GNU_RETAIN is yours.
Since gold is not built by default, should we just disable SHF_GNU_RETAIN support if gold has been built at all, for Binutils versions without the gold patch. There's 2 weeks between the GCC "used" implying SHF_GNU_RETAIN patch and gold being fixed, so the real fix if you want SHF_GNU_RETAIN support but are using a Binutils version in this timeframe is to just upgrade. Meanwhile we should just completely turn off SHF_GNU_RETAIN if GCC can spot that a broken gold is available.
Since gold has been fixed now, you can add a check for broken gold and set HAVE_GAS_SHF_GNU_RETAIN to 0 for broken gold.
I've posted a patch where the HAVE_GAS_SHF_GNU_RETAIN configure test has been extended to check for SHF_GNU_RETAIN gold support: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562100.html
This also needs a backport to 10? Can someone please fill in the known_to_{work,fail} fields?
Isn't this problem gone with r11-7284-g6347f4a0904fce17eedf5c071be6f3c118680290 ? I mean, attribute used now means what it used to mean before, and retain attribute is not used in whatever is emitted into .init_array section at least in existing code. Yes, one might use it in user code, but the answer can be don't do it then.
I believe this PR only relates to the fact that GCC support for SHF_GNU_RETAIN was available before GOLD supported that section flag. My proposed patch was to turn off GCC support for SHF_GNU_RETAIN if an unsupported GOLD is detected. I think at this point, the GOLD functionality was only broken for such a narrow period of time in development (not corresponding to a concrete version of Binutils), there's no point adding a configure test to try and catch that now. (In reply to Jakub Jelinek from comment #8) > Isn't this problem gone with > r11-7284-g6347f4a0904fce17eedf5c071be6f3c118680290 ? > I mean, attribute used now means what it used to mean before, and retain > attribute is not used in whatever is emitted into .init_array section at > least in existing code. Yes, one might use it in user code, but the answer > can be don't do it then. And yes, since none of the libraries using the "used" attribute will implicitly create SHF_GNU_RETAIN sections any more, even if you used the Binutils version with broken GOLD, it won't cause any problems.
I think its best to close this as WONTFIX. GCC will only erroneously enable SHF_GNU_RETAIN support if a Binutils version between: > commit 99fabbc9739a87ba3433e66792e93b773896790e > Author: Jozef Lawrynowicz <jozef.l@mittosystems.com> > Date: Wed Nov 18 11:51:13 2020 +0000 > > Support SHF_GNU_RETAIN ELF section flag and > commit ff4bc37d77a0ca7286883a477adcb3aa145fc782 > Author: Cary Coutant <ccoutant@gmail.com> > Date: Mon Dec 14 15:46:47 2020 -0800 > > Keep input SHF_GNU_RETAIN sections and strip output SHF_GNU_RETAIN for GNU/FreBSD ELFOSABIs. is being used. There's no Binutils release in this range.