<div dir="ltr">Looks like there's a bug. It's weird that the existing test didn't catch that. I'll probably need to fix the ordinal of alias atoms.<div><br></div><div>LayoutPass is retired peacefully. I know that code very well, because after you added code to that file for follow-on/followed-by relations, I spend so much effort improving that functionality while keeping the original intention. I refactored it for readability, fixed various bugs, improved performance (originally it was even quadratic), and added bunch of (overly-designed in hindsight) assertions to verify that too-flexible complex data structure is in a well-formed shape. Eventually I had to conclude that this was not a good design after all -- it was too complicated compared to what it would do. So I cannot agree.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 12, 2015 at 10:44 AM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
It looks like the COFF reader creates an Alias atom by adding a kindLayoutAfter reference to the target atom. Now since the kindLayoutAfter passes are moved to machO how does it still work ?<br>
<br>
Does it work by chance because of ordinals ? I would think moving kindLayoutAfter references and having the LayoutPass would be a better choice.<span class="HOEnZb"><font color="#888888"><br>
<br>
Shankar Easwaran<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</font></span></blockquote></div><br></div>