Nick Kledzik <[EMAIL PROTECTED]> writes: > On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote: >> Nick Kledzik <[EMAIL PROTECTED]> 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? Ian
