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

[Bill Wendling]

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.

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?

-bw