$ >reproducer.sh cat <<EEOOFF #!/bin/sh test \$# -gt 0 || { echo 'specify linker (bfd|gold)'; exit 1; } gcc -o lib_conftest.so -g -O2 -shared -fPIC -xc - <<EOF #include <assert.h> extern int __start___verbose[], __stop___verbose[]; int test(void) { static int my_var __attribute__((section("__verbose"))) = 3; assert(("L:non-empty data section", __start___verbose != __stop___verbose)); assert(("L:no data section value loss", my_var == 3 /* for 2.29.1+ */)); return *((int *) __start___verbose); } EOF gcc -o conftest -fuse-ld="\$1" -xc - -L. -l_conftest -Wl,-rpath=$(pwd) <<EOF #include <assert.h> extern int __start___verbose[], __stop___verbose[]; int test(void); int main () { static int my_var __attribute__((section("__verbose"))) = 5; assert(("P:non-empty data section", __start___verbose != __stop___verbose)); assert(("P:no data section value loss", my_var == test() /*5?*/)); return 0; } EOF ./conftest echo '(for cleanup, run: rm -f -- lib_conftest.so conftest)' EEOOFF $ sh reproducer.sh bfd > conftest: <stdin>:8: main: Assertion `("P:no data section value loss", my_var == test() )' failed. > reproducer.sh: line 28: 22163 Aborted (core dumped) ./conftest > (for cleanup, run: rm -f -- lib_conftest.so conftest) $ sh reproducer.sh gold > ./conftest: error while loading shared libraries: unexpected reloc type 0x0b ^ this line from the run-time is not expected > (for cleanup, run: rm -f -- lib_conftest.so conftest) $ rpm -q binutils gcc glibc > binutils-2.29.1-2.fc28.x86_64 > gcc-7.2.1-1.fc28.x86_64 > glibc-2.26.90-18.fc28.x86_64 Note that with binutils 2.28 (binutils-2.28-14.fc27.x86_64), the "bfd" output changes ("gold" one remains the same) in a way that no assertion is raised (but this was already widely covered in [bug 1477354]).
Created attachment 1337321 [details] output from "LD_DEBUG=all ./conftest"
Hi Jan, Do you have any objections to my filing this bug report, and especially the reproducer, with the upstream FSF binutils ? I would like to get the gold experts there to have a look at the problem. Cheers Nick
No problem at all, actually thanks for the offer. (says lazy me, lazy to open an account over there)
No worries - it is all part of the service. :-) I have now submitted the bug upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=22291
Hi Jan, H.J.Lu has created a patch that fixes the problem. I have imported it into rawhide, so if you try out: binutils-2.29.1-3.fc28 you should find that things now work. Cheers Nick
Thanks Nick (and H.J.Lu), confirming that "gold" output now matches the "bfd" one. Running slightly off-topic now, how probable do you think is that GOLD gets rid of this restriction (linker script is akin to the one discussed in [bug 1477354 comment 8]): $ gcc -o conftest -fuse-ld=gold -Wl,conftest.ld conftest.c > SECTIONS seen after other input files; try -T/--script Vague guess is that it's also related to alleged GOLD's inability to use INSERT AFTER (https://stackoverflow.com/a/16756006)? Or contrary, what's the risk of ld.bfd likewise dropping the support for what currently just triggers a warning as previously discussed?
Hi Jan, > Running slightly off-topic now, how probable do you think is that > GOLD gets rid of this restriction (linker script is akin to > the one discussed in [bug 1477354 comment 8]): Hmm, not sure. I think that if enough users complained the upstream GOLD maintainers might take note and try to do something about it. Even better of course would be if someone submitted a patch to fix the problem. > Vague guess is that it's also related to alleged GOLD's inability > to use INSERT AFTER (https://stackoverflow.com/a/16756006)? Right - gold tries to be "script-less", instead relying upon built in algorithms to place sections correctly. Personally I think that this is a bad idea, but then I am not a gold developer. > Or contrary, what's the risk of ld.bfd likewise dropping the support > for what currently just triggers a warning as previously discussed? I very much doubt that ld.bfd will drop this support, and since I do maintain it, I can assure you that support will remain. Cheers Nick
re [comment 7]: >> Or contrary, what's the risk of ld.bfd likewise dropping the support >> for what currently just triggers a warning as previously discussed? > > I very much doubt that ld.bfd will drop this support, and since I do > maintain it, I can assure you that support will remain. Thanks; I was just worried if one way of possible convergence (if that's generally accepted as desirable -- indeed, I don't know) is blocked that the opposite might be promoted (under cleanliness claims or what not). So good to have some assurance it's not foreseeably the case.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Confirming the fix as of binutils-2.33.1-10.fc32.x86_64 at latest.