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

[Lang Hames via Phabricator via llvm-commits]

lhames added a comment.

I just read up on the details here -- https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#auxiliary-format-3-weak-externals. I was too focused on the `Weak` bit, not enough on the "External" bit. :)

> @lhames 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."

Let me see if I understand these modes:

`weak_alias` -- A weak extern with `Characteristics == IMAGE_WEAK_EXTERN_SEARCH_ALIAS`. Should be treated as a weak alias (we should introduce a proper alias concept into JITLink)
`alternatename` -- A weak extern with either `Characteristics == IMAGE_WEAK_EXTERN_SEARCH_LIBRARY` or `Characteristics == IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY`. Should be treated as a weak-ref of the external name, but transform into an alias for the alternatename if the external name is not found. The Characteristics determine whether the weak-ref should proceed into other libraries, or stay within the current one.

Does that sound right?

I think that we probably need new `LinkGraph` infrastructure for this, but I don't think a new LinkageType is the right approach. I suspect that we want to define symbol alias support, and encode this behavior into that. I'll wait to get confirmation from you about how I'm looking at this before I dig too much deeper though.


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

https://reviews.llvm.org/D130449