[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product

2018-07-04 Thread zenith432 at users dot sourceforge.net
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

2018-06-21 Thread zenith432 at users dot sourceforge.net
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

2018-06-18 Thread zenith432 at users dot sourceforge.net
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

2018-06-18 Thread amonakov at gcc dot gnu.org
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

2018-06-18 Thread zenith432 at users dot sourceforge.net
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

2018-06-18 Thread rguenth at gcc dot gnu.org
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