bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/23935] [Regression] ld.bfd does not rescan fat LTO archives to r


From: vlad at ispras dot ru
Subject: [Bug ld/23935] [Regression] ld.bfd does not rescan fat LTO archives to resolve plugin-added references
Date: Mon, 03 Dec 2018 20:38:52 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=23935

--- Comment #7 from Vladislav Ivanishin <vlad at ispras dot ru> ---
(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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]