Nick Kledzik <kledzik@apple.com> writes:
On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote:
Nick Kledzik <kledzik@apple.com> writes:
I don't claim our current implementation is bug free, but the lto
interface
matches the Apple linker internal model, so we don't expect and
have
not encountered any problems mixing mach-o and llvm bitcode files.
Hmmm, OK, how about this example:
a.o: contains LTO information, refers to S
b.o: no LTO information, defines S
c.o: contains LTO information, defines S at version V, S/V is not
hidden
In the absence of b.o, the reference to S in a.o will be resolved
against the definition of S in c.o. In the presence of b.o, the
reference to S in a.o will be resolved against the definition of S
in
b.o.
I suppose we could refuse to inline versioned symbols, but that
doesn't seem desirable since it is normally fine.
As Chris mentioned earlier today, the Apple tool chain does not
support versioned symbols.
But if versioned symbols are a naming convention (that is everything
is encoded in
the symbol name), then this would work the same as your previous
example. Namely,
the linker would coalesce away S in c.o, which in turns tell the LTO
engine that it
can't inline/optimize away c.o's S and after LTO is done, the linker
throws away
the LTO generated S and uses b.o's S instead.
Versioned symbols are not a naming convention, but they aren't all
that different from one. Basically every symbol may have an optional
version, and when a symbol has a version the version may be hidden or
not. A symbol definition with a hidden version may only be matched by
a symbol reference with that exact version. A symbol definition with
a non-hidden version definition may be matched by a symbol reference
with the same name without a version. This is most interesting in the
dynamic linker, of course.
How does the linker inform the plugin that the plugin is not permitted
to use c.o's S?