Hi, 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 ? Does it work by chance because of ordinals ? I would think moving kindLayoutAfter references and having the LayoutPass would be a better choice. Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
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. 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. On Thu, Feb 12, 2015 at 10:44 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:> Hi, > > 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 ? > > Does it work by chance because of ordinals ? I would think moving > kindLayoutAfter references and having the LayoutPass would be a better > choice. > > Shankar Easwaran > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by the Linux Foundation > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150212/6706061c/attachment.html>
On 2/12/2015 2:26 PM, Rui Ueyama wrote:> 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. > > 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.The whole point of LayoutPass was it was reference based previously and now its ordinal based. It was more generic previously(though we didnt need that complexity). Shankar Easwaran> On Thu, Feb 12, 2015 at 10:44 AM, Shankar Easwaran <shankare at codeaurora.org> > wrote: > >> Hi, >> >> 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 ? >> >> Does it work by chance because of ordinals ? I would think moving >> kindLayoutAfter references and having the LayoutPass would be a better >> choice. >> >> Shankar Easwaran >> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >> by the Linux Foundation >> >>-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation