https://sourceware.org/bugzilla/show_bug.cgi?id=23935
Vladislav Ivanishin <vlad at ispras dot ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from Vladislav Ivanishin <vlad at ispras dot ru> ---
GCC does not tell it needs the printf symbol, because it's a builtin function
(prog.c is compiled without -fno-builtin).
At the time of writing LTO IR, GCC does not know what symbols will be needed
for
implementing builtins; this information becomes available only during the
actual
LTO. (Beforehand GCC could only tell it needed printf, but of what use is that
knowledge, if in fact it will be transformed into a reference to puts in the
end?)
Resolving such new LTO-generated references is what rescanning is for, isn't
it?
> In fact, ld is consistent for with and without -ffat-lto-objects.
Yes, and my point is it shouldn't be.
During the rescan (no_more_claiming is set) in add_archive_element(), the
decision not to add libfoo.o to the link is made regardless of it having
regular
object code:
plugin_maybe_claim (input);
if (input->flags.claimed)
{
...
}
plugin_maybe_claim() calls plugin_object_p(), which returns a positive result
for both slim and fat lto objects.
Now, if the linker sees a file containing nothing but LTO IR during rescan, it
should indeed ignore it (LTO phase is over). But if the file has non-LTO code
as
well, that should be used to resolve references as if the file did not contain
any LTO IR at all.
Gold works as expected and so did ld releases prior to 2.27
(https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b95a0a3177bcf797c8f5ad6a7d276fb6275352b7
is the culprit).
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
