[llvm-commits] [llvm] r114868 - in /llvm/trunk: include/llvm-c/lto.h tools/lto/LTOModule.cpp

[Bill Wendling]

On Sep 27, 2010, at 8:09 PM, Nick Lewycky wrote:

> Bill Wendling wrote:
>> On Sep 27, 2010, at 2:10 PM, Nick Lewycky wrote:
>> 
>>> Hi Bill,
>>> 
>>> It's not clear to me what this new bit actually means. How should I treat this in the gold plugin? What does it do in ELF?
>>> 
>>> Looking at the LangRef, it's not clear to me that linker_private_weak_def_auto is a good orthogonal abstraction either. It makes sense if you really do have a language feature where taking the address doesn't preserve the uniqueness of the address, but the two cases I'm interested in are C strings (where this is true, but the linkage type isn't obviously "linker_private_weak") and virtual functions (whose addresses appear in the vtable constant, but those addresses are never compared, only called through).
>>> 
>>> I realize this is solving a real problem for you, but would you mind taking a minute to explain what's going on? The example in the LangRef sounds like it would be solved with "available_externally" linkage, for example, could it?
>>> 
>> Not really.
>> 
>> The motivation behind this new linkage type is to limit the number of weak symbols that we generate in the final linked image – executable or library. Templates are an example of why this is important. They are instantiated in multiple translation units, but if the address of a template function is never taken we know that the dynamic linker doesn't need to unique them. The static linker can then make the object hidden.
> 
> Interesting. So the linker does this on real .o files, not at LTO time within llvm? That makes this a lot more clear.

Yup! :-)

> The issue doesn't come up in LTO because they would either be deleted or become 'internal' linkage.
> 
Pretty much. The linker merges the modules. Then the linkage type is handled in the "normal" fashion from bitcode to object file code.

>> The Mach-O linker implements this with the .weak_def_can_be_hidden directive. I don't think your linker has this feature (yet). So I think it should be treated as a normal "weak" definition.
>> 
>> Does that sound good?
> 
> Okay, it sounds like this will never come up when building on an ELF system, so I'm satisfied that I can pretty much continue to ignore it :)
> 
Just make sure that your code can handle the LLVM linkage type. I think you're safe treating it as a weak definition...

> Thanks for taking the time to explain it!
> 
Of course! :)

-bw