RFC: New Linkage Type linker_private_weak

This patch introduces a the new "linker_private_weak" linkage type.

Why a new linkage type? The idea behind the "linker" linkage types is that they are used by the linker and then discarded. I.e., the symbols won't show up in the final linked image. In that regard, all "linker" linkage types are inherently "private". The "linker" linkages are currently used only by Objective-C metadata, and only Darwin's linker has the facility to handle them. However, they aren't restricted to Objective-C metadata or Darwin.

The "linker_private_weak" linkage has similar semantics to the "linker_private" linkage: it's private to the linkage unit and doesn't appear in the final linked image. Unlike the linker_private linkage, it has a "weak" definition. For example:

  .private_extern l_objc_msgSend_fixup_alloc
  .globl l_objc_msgSend_fixup_alloc
  .weak_definition l_objc_msgSend_fixup_alloc
  .section __DATA, __objc_msgrefs, coalesced
  .align 3
l_objc_msgSend_fixup_alloc:
  .quad _objc_msgSend_fixup
  .quad L_OBJC_METH_VAR_NAME_1

Whereas something with "linker_private" linkage has a strong definition, but unlike a normal strong definition is removed by the linker:

  .align 3
l_OBJC_METACLASS_RO_$_A:
  .long 3
  .long 40
  ...

I implemented the new linkage to have its own prefix from linker_private. As it currently stands, the symbol's prefix ("l") is the same for "linker_private" and "linker_private_weak". If this will always be the case, then I can remove the code in my patch that allows for a different prefix.

Comments?

-bw

linker_private_weak.patch (18.8 KB)

This patch introduces a the new "linker_private_weak" linkage type.

Why a new linkage type? The idea behind the "linker" linkage types is that they are used by the linker and then discarded. I.e., the symbols won't show up in the final linked image. In that regard, all "linker" linkage types are inherently "private". The "linker" linkages are currently used only by Objective-C metadata, and only Darwin's linker has the facility to handle them.

Right.

However, they aren't restricted to Objective-C metadata or Darwin.

I'd say that the semantics aren't darwin-specific, but it is very unlikely that any other target would actually implement them. In this way, they are similar to dllimport/dllexport which really are windows specific even though they could be described in a target independent way.

The "linker_private_weak" linkage has similar semantics to the "linker_private" linkage: it's private to the linkage unit and doesn't appear in the final linked image. Unlike the linker_private linkage, it has a "weak" definition.

In other words, "redefinitions are merged, not reported as errors".

I implemented the new linkage to have its own prefix from linker_private. As it currently stands, the symbol's prefix ("l") is the same for "linker_private" and "linker_private_weak". If this will always be the case, then I can remove the code in my patch that allows for a different prefix.

I'm quite certain that it will always be the case :), please remove MAI::LinkerPrivateWeakGlobalPrefix and Mangler::LinkerPrivateWeak.

Otherwise, the patch looks good. Please commit it with 1) a testcase showing the next linkage type round trips through llvm-as/llvm-dis (in llvm/test/Feature/) 2) a codegen test for at least one darwin target that filechecks that the right directives are being generated. 3) a LangRef.html patch.

Thanks again for working on this!

-Chris

I implemented the new linkage to have its own prefix from linker_private. As it currently stands, the symbol's prefix ("l") is the same for "linker_private" and "linker_private_weak". If this will always be the case, then I can remove the code in my patch that allows for a different prefix.

I'm quite certain that it will always be the case :), please remove MAI::LinkerPrivateWeakGlobalPrefix and Mangler::LinkerPrivateWeak.

Okay. I'll go ahead and make this change. I'm not a big fan (I'd rather it be more general), but I'm not going to stand in the way of getting this to work either. :slight_smile:

Otherwise, the patch looks good. Please commit it with 1) a testcase showing the next linkage type round trips through llvm-as/llvm-dis (in llvm/test/Feature/) 2) a codegen test for at least one darwin target that filechecks that the right directives are being generated. 3) a LangRef.html patch.

Yup! I already have these in my tree, more or less. :slight_smile:

Thanks again for working on this!

Sure!

-bw

Awesome, thanks Bill!

-Chris