[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 zenith432 at users dot sourceforge.net changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|MOVED |FIXED --- Comment #6 from zenith432 at users dot sourceforge.net --- This bug is fixed in binutils master. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=94d401b8b88a76b1372ce44e805516756a4f737b
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 --- Comment #5 from zenith432 at users dot sourceforge.net --- This is a bug in ld.bfd. It's setting the resolution for entry symbols to LDPR_PREVAILING_DEF_IRONLY_EXP instead of LDPR_PREVAILING_DEF. gold handles them right. I posted a patch in the sourceware bugzilla linked above at comment 3.
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 zenith432 at users dot sourceforge.net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #4 from zenith432 at users dot sourceforge.net --- Done. https://sourceware.org/bugzilla/show_bug.cgi?id=23309
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- > but really gets an empty blob from the LTO plugin for foo. Are you sure about this? Compiling with -save-temps shows that the symbol is present in GCC's assembly output; specifying --print-gc-sections also shows that the linker is discarding it: /usr/bin/ld.bfd: Removing unused section '.text.KeepMe' in file '/tmp/ccWbtSKK.ltrans0.ltrans.o' Gold linker does not exhibit this (try -fuse-ld=gold). Can you report it against the BFD linker at sourceware.org/bugzilla?
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- With ld 2.30 it seems to work for me with a simple void foo () {} int main() { return 0; } > gcc-8 t.c -flto -O -Wl,-u,foo,--gc-sections -ffunction-sections --- Comment #2 from zenith432 at users dot sourceforge.net --- It's the visibility that breaks it. Try gcc-8 t.c -flto -O -Wl,-u,foo,--gc-sections -ffunction-sections -fvisibility=hidden Here's a full summary of observed behavior Without '-u foo', foo gets discarded for both LTO, non-LTO build and with any visibility. With '-u foo' On non-LTO build, foo always gets forced in regardless of visibility. The symbol's visibility is not supposed to play a role in the decision-making of applying the '-u foo'. On LTO build - if foo's visibility is either default or protected, it gets forced in. - if foo's visibility is either hidden or internal, it gets discarded. The reason I opened this bug against GCC and not LD - is that LD does not complain about an undefined foo even if '--require-defined=foo' is used in place of '-u foo'. LD believes it is force-including foo, but really gets an empty blob from the LTO plugin for foo.
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- With ld 2.30 it seems to work for me with a simple void foo () {} int main() { return 0; } > gcc-8 t.c -flto -O -Wl,-u,foo,--gc-sections -ffunction-sections