[PATCH] Fix Weak External symbol handling.

Rui Ueyama ruiu at google.com
Tue Nov 19 11:00:49 PST 2013


On Tue, Nov 19, 2013 at 8:41 AM, Shankar Kalpathi Easwaran <
shankarke at gmail.com> wrote:

>
>   I still think that this is being called too early. I thought the
> fallback atom would only be used as a target for resolution only if the
> original undefined symbol stays as undefined. With the current approach I
> dont think its fixed.
>
>   Consider object files mixed with multiple archive files and shared
> libraries. The undefined atom would be only picked up after only looking up
> the archive library. It makes it more harder as soon as you see a mix of
> shared libraries and archive libraries which define the symbol too.
>
>   This is the extract that I read from, I am sure you already know this, I
> am only mentioning this for the purpose of discussion.
>
>   <--------------------snip--------------------------->
>
>   “Weak externals” are a mechanism for object files that allows
> flexibility at link time.
>
>   A module can contain an unresolved external symbol (sym1), but it can
> also include an auxiliary record that indicates that if sym1 is not present
> at link time, another external symbol (sym2) is used to resolve references
> instead.
>
>   If a definition of sym1 is linked, then an external reference to the
> symbol is resolved normally. If a definition of sym1 is not linked, then
> all references to the weak external for sym1 refer to sym2 instead. The
> external symbol, sym2, must always be linked; typically, it is defined in
> the module that contains the weak reference to sym1.
>
>   <--------------------snip--------------------------->
>

The MS PE/COFF spec is awfully vague at this point. My first interpretation
of this section was similar to yours, and the implementation I actually did
was somewhat different from that, but it's proved that both are wrong. We
cannot really trust this section -- only we can do is to run link.exe and
observe the behavior.

This revised patch is based on my observation on the actual behavior of
link.exe. link.exe seems that it will *immediately* replace sym1 with sym2
if sym1 is not defined when a file containing undefined symbol sym1 (with
fallback sym2) is loaded. It might seem odd, but as a matter of fact, the
patch reflects the (unwritten) spec of COFF.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131119/f2c1b73c/attachment.html>


More information about the llvm-commits mailing list