On Jun 5, 2008, at 6:59 AM, Ian Lance Taylor wrote:
"Rafael Espindola" <[EMAIL PROTECTED]> writes:
Interesting. The use of lto_codegen_add_must_preserve_symbol is kind
of the opposite of what I had understood. What do you do in this
case:
a.o: IL file that contains a reference to "f"
b.o: IL file that has a weak def of "f"
There is no strong definition. Can you inline f into the use in a.o?
I don't know what LLVM does, but in principle, in ELF, you can do this
inlining when linking an executable, but not when linking a shared
library. Actually, when linking a shared library, what matters is not
whether the definition of "f" is weak or not, but what the visibility
of 'f" is (default, hidden, protected, or internal). And, of course,
the visibility of "f" can be set by link-time options (e.g.,
-Bsymbolic).
In LLVM LTO, the model is that the linker is the one that knows about
visibility. The problem is that 'hidden' is not sufficient to capture
visibility info when mixing LTO modules with native ones. If you
have: [a-c].c and compile [ab].c with LTO and c.c without, any hidden
symbols should be visible outside the [ab].o LTO region.
LLVM LTO handles this by marking symbols "internal" (aka static, aka
not TREE_PUBLIC, whatever) when the symbol is not visible outside the
LTO scope. This allows the optimizers to go crazy and hack away at
the symbols, but only when safe.
'Weakness' only matters when a symbol is exported from the LTO scope,
so 'weak' and 'visibility' are orthogonal.
-Chris
