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

[Nick Lewycky]

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. The issue doesn't come up 
in LTO because they would either be deleted or become 'internal' linkage.

> 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 :)

Thanks for taking the time to explain it!

Nick