<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 19, 2013 at 8:41 AM, Shankar Kalpathi Easwaran <span dir="ltr"><<a href="mailto:shankarke@gmail.com" target="_blank">shankarke@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  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.<br>


<br>
  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.<br>


<br>
  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.<br>
<br>
  <--------------------snip---------------------------><br>
<br>
  “Weak externals” are a mechanism for object files that allows flexibility at link time.<br>
<br>
  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.<br>


<br>
  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.<br>


<br>
  <--------------------snip---------------------------><br></blockquote><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

</div></div></div>