[whopr] Design/implementation alternatives for the driver and WPA

[Nick Kledzik]

On Jun 4, 2008, at 5:39 PM, Ian Lance Taylor wrote:
> 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?
In the previous case where S was weak, the call to  
lto_codegen_add_must_preserve_symbol("S")
caused the LTO engine to know it could not inline S (because it was
a weak definition and used outside the LTO usage sphere). And then
after LTO was done, the linker threw away the LTO produced S and used
the one from c.o instead.

In this case S is a regular symbol.  So the previous trick won't  
work.  Probably
the best solution would be to add a new  lto_ API to tell the LTO  
engine to
ignore a definition is already has.  It would make more sense to use  
this
new API in the weak case too.

-Nick