[Top][All Lists]

[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 15:59:43 +0000


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

reply via email to

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