[Bug ld/23935] [Regression] ld.bfd does not rescan fat LTO archives to resolve plugin-added references
https://sourceware.org/bugzilla/show_bug.cgi?id=23935 --- Comment #11 from Vladislav Ivanishin --- (In reply to H.J. Lu from comment #10) > Please try: > > https://sourceware.org/ml/binutils/2018-12/msg00112.html Works for me. -- 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
[Bug ld/23935] [Regression] ld.bfd does not rescan fat LTO archives to resolve plugin-added references
https://sourceware.org/bugzilla/show_bug.cgi?id=23935 --- Comment #9 from Vladislav Ivanishin --- > --- Comment #8 from H.J. Lu --- > Please try users/hjl/lto-mixed/master branch with > > commit 08c2f8679f999afaf59d9bc378ef2ff51ed5f40f > Author: H.J. Lu > Date: Thu Dec 6 11:45:41 2018 -0800 > > Don't claim a fat IR object if no IR object should be claimed > > It it works, I will port it to master branch. It does; this patch solves it for all the tests I have that previously exposed the problematic behavior. Thank you! -- 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
[Bug ld/23935] [Regression] ld.bfd does not rescan fat LTO archives to resolve plugin-added references
https://sourceware.org/bugzilla/show_bug.cgi?id=23935 --- Comment #7 from Vladislav Ivanishin --- (In reply to H.J. Lu from comment #6) > The behaviors of with and without -ffat-lto-objects should be the same. > Either both work or both don't. Why? I think the behavior of 'with -ffat-lto-objects' here for libfoo.o should match that of 'without -flto at all'. (Which it doesn't.) The test case in the original post is a minified illustration of a bigger test case. And -ffat-lto-objects is there because it allows to reuse the same static archive for dependency resolution on the first pass of the linker (IR in the archive members benefits LTO compilation), and for the rescanning pass, where no_more_claiming is set and the fat archive is acting in the capacity of a regular non-LTO archive. If for this minified test case we compile libfoo instead with just gcc -c -fno-builtin libfoo.c -o libfoo.o , then the rescanning works as expected. Adding IR to libfoo should not change anything, because the linkers currently are not supposed to rescan LTO objects iteratively until reaching a fixed point---rather, they do exactly 2 passes, disregarding IR during the second. My understanding is that fat objects are a possibility (they provide a fallback i.e. the linker should find the appropriate resolution, if it's there), not an imperative to treat them as IR objects. -- 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
[Bug ld/23935] [Regression] ld.bfd does not rescan fat LTO archives to resolve plugin-added references
https://sourceware.org/bugzilla/show_bug.cgi?id=23935 --- Comment #5 from Vladislav Ivanishin --- (In reply to H.J. Lu from comment #4) > (In reply to Vladislav Ivanishin from comment #3) > > GCC does not tell it needs the printf symbol, because it's a builtin > > function > > (prog.c is compiled without -fno-builtin). > > > > Although printf is a builtin function, it doesn't mean that GCC doesn't > need an external symbol, which doesn't have to be printf, to implement > the builtin function. GCC should put that external symbol in the LTO > symbol table. The compiler would then add a superset of references compared to what will actually be needed. The decision whether to emit a call or inline code for a builtin is made during LTO. Not to mention that this would be hard to track in the compiler: say, builtin_strcpy might be folded to builtin_memcpy. So in the end either of the libc functions might be called, or none at all if the builtin is emitted completely as inline code. In the approach you suggest files containing both functions will always be extracted from libc. AFAIK the rescanning functionality was added to support exactly this use case, namely "to ensure that any previously unseen undefined symbols introduced by the compiler are handled correctly" (quoting [1]). Why rescan anything at all if we know the symbol tables beforehand? [1]: https://sourceware.org/ml/binutils/2011-01/msg00270.html -- 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
[Bug ld/23935] [Regression] ld.bfd does not rescan fat LTO archives to resolve plugin-added references
https://sourceware.org/bugzilla/show_bug.cgi?id=23935
Vladislav Ivanishin changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from Vladislav Ivanishin ---
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
[Bug ld/23935] [Regression] ld.bfd does not rescan fat LTO archives to resolve plugin-added references
https://sourceware.org/bugzilla/show_bug.cgi?id=23935 Vladislav Ivanishin changed: What|Removed |Added Summary|ld.bfd does not rescan fat |[Regression] ld.bfd does |LTO archives to resolve |not rescan fat LTO archives |plugin-added references |to resolve plugin-added ||references --- Comment #1 from Vladislav Ivanishin --- This is actually a regression introduced in the fix for PR 20103. -- 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
[Bug ld/23935] New: ld.bfd does not rescan fat LTO archives to resolve plugin-added references
https://sourceware.org/bugzilla/show_bug.cgi?id=23935
Bug ID: 23935
Summary: ld.bfd does not rescan fat LTO archives to resolve
plugin-added references
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: vlad at ispras dot ru
Target Milestone: ---
#!/bin/sh -
cat > prog.c << EOF
#include
int main() { printf("hi\n"); return 0; }
EOF
cat > libfoo.c << EOF
#include
int puts(const char *s) { return 0; }
EOF
gcc -c -flto -fno-builtin -ffat-lto-objects libfoo.c -o libfoo.o
ar rcs libfoo.a libfoo.o
# gold="-fuse-ld=gold"
gcc -c -flto prog.c -o prog.o
gcc $gold -Wl,-emain -L. -static -nostdlib prog.o -lfoo
>From <https://sourceware.org/ml/binutils/2014-08/msg00025.html> I gather that
in
the presence of LTO recompiled objects, the archives are supposed to be
rescanned automatically. This does not happen in the example above.
When LTOing prog.o, GCC transforms the printf call to a puts call. I expect
this
new call to see a resolution in libfoo.a. And it happens indeed, if one uses
Gold. Not so for the BFD linker:
/usr/bin/ld: /tmp/ccvITLI4.ltrans0.ltrans.o: in function `main':
:(.text+0xc): undefined reference to `puts'
Notice the -ffat-lto-objects switch. Without it, libfoo.a would contain only
LTO bytecode and both linkers would error out. It seems, the logic is off
somewhere taking "contains LTO bytecode" for "contains only LTO bytecode".
--
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
[Bug ld/23426] ld manual is inconsistent with reality w.r.t. default --hash-style value
https://sourceware.org/bugzilla/show_bug.cgi?id=23426 Vladislav Ivanishin changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #1 from Vladislav Ivanishin --- There is no shame in referring to configure options in the manual. Take GCC man for example: -fdiagnostics-color[=WHEN] -fno-diagnostics-color Use color in diagnostics. WHEN is never, always, or auto. The default depends on how the compiler has been configured, it can be any of the above WHEN options or also never if GCC_COLORS environment variable isn't present in the environment, and auto otherwise. -- 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
[Bug ld/23426] New: ld manual is inconsistent with reality w.r.t. default --hash-style value
https://sourceware.org/bugzilla/show_bug.cgi?id=23426 Bug ID: 23426 Summary: ld manual is inconsistent with reality w.r.t. default --hash-style value Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: vlad at ispras dot ru Target Milestone: --- This was introduced in 2760f24c4942853eac7b921e4b8843d57a602654 where the default hash style was made configurable. The documentation (ld/ld.texi) should reflect this change. Currenly it says '--hash-style=STYLE' ... The default is 'sysv'. For all platforms and configurations (and this is now false by default for e.g. x86-64 linux). -- 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
[Bug gold/22500] make -k check-gold errors in passing option
https://sourceware.org/bugzilla/show_bug.cgi?id=22500 Vladislav Ivanishin changed: What|Removed |Added CC||vlad at ispras dot ru --- Comment #2 from Vladislav Ivanishin --- I experienced the same problem with gold built from source (today's master branch). You have to pass --enable-plugins to configure for gold to recognize --plugin* options. Here's binutils-gdb configured with `--enable-gold --enable-plugins`: $ gold/ld-new -plugin plug gold/ld-new: error: plug: could not load plugin library: plug: cannot open shared object file: No such file or directory gold/ld-new: fatal error: no input files (This is a correct diagnostic.) And here's the same revision configured with just `--enable-gold`: $ gold/ld-new -plugin plug gold/ld-new: error: cannot open plug: No such file or directory gold/ld-new: error: cannot find -lugin Also note that the diagnostic emitted by ld.bfd is the same for both configurations: $ ld/ld-new -plugin plug ld/ld-new: plug: error loading plugin: plug: cannot open shared object file: No such file or directory -- 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
[Bug gold/22694] [2.30 Regression] -fuse-ld=gold not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=22694 Vladislav Ivanishin changed: What|Removed |Added CC||vlad at ispras dot ru -- 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
[Bug ld/22649] -gc-sections preserves hidden symbols that are also visible in dynamic objects
https://sourceware.org/bugzilla/show_bug.cgi?id=22649 Vladislav Ivanishin changed: What|Removed |Added CC||vlad at ispras dot ru -- 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
