[PATCH] D130449: [JITLink] Introduce WeakExternal linkage type.

Sunho Kim via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 25 20:20:24 PDT 2022


sunho added a comment.

In D130449#3678079 <https://reviews.llvm.org/D130449#3678079>, @lhames wrote:

>> "If a definition of external symbol is linked, then an external reference to the symbol is resolved normally. If a definition of external symbol is not linked, then all references to the weak external for external symbol refer to stub symbol instead."
>
> This is curious. Is it just a weaker weak? I.e. "Prefer another weak def if you have one, but use me as a last resort"? What happens if you have multiple instances of a symbol all tagged with this linkage? Does the linker just choose arbitrarily the same way that it would for a regular weak symbol? And how does this interact with COMDATs? Or is it never used on symbols in COMDAT sections?
>
> If this behaves differently to "weak" or "strong" we'll need a new JITSymbolFlag for it too, and handling in the ORC symbol tables.

The way I understand this now is that the characteristics flag decide whether it will be exported to the external objects or not. For instance, if anything else than weak_alias flag is used it will be set "SF_undefined" in symbol list provided in libObject implementation. So, technically weak_alias is more similar to traditional weak symbol while other flags like search_library/no_library are "really weak."

For weak_alias case, it's fine to deal it with weak linkage type as they will be visible to the outside world and potentially crash with strong definition. But, for search_library and alternatename case, it will be not visible in symbol list cause SF_undefined flag is set or symbol is just not in symbol table. In this case, strong definition will not even be emitted so they don't get a chance to even crash with strong definition, or user provided definition is ignored.

For COMDATs, they are fine to be dealt with weak as they are always visible to external world AFAIK. There is one inaccuracy in how we're dealing with them -- strong + COMDAT any is duplicate definition error. But, I think that is fine.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130449/new/

https://reviews.llvm.org/D130449



More information about the llvm-commits mailing list