<div dir="ltr">Hi Rafael,<div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">As far as I know MC doesn't have a robust symbolic arithmetic expression evaluator.</span>  </blockquote></div></div></blockquote><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It does. It has to have one. Without one it would be unable to know what value to write in the symbol table.</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">The key phrase is robust. We have an arithmetic expression evaluator, but I believe it only handles simple expressions.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If I'm mistaken and MC can handle arbitrarily complex symbolic expressions then there's no problem - we run the expression evaluator on the alias and if the displacement is constant '0' we don't set .alt_entry.</div><div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">Not sure what you mean. You have "bar = expression with bar in it"<br></span><span style="font-size:13px">which I hope is an error.</span></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">Apologies - the example may not have been clear. The point was that the expression didn't have to reference bar, it just had to yield a value that was significant. In this example, try substituting any expression at all that ultimately evaluates to -1. Assuming this is x86 code, you now have bar = foo.</div><div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">If ld64 cannot handle it than doing this in MC is even more important.</span></blockquote><div class="gmail_extra"><span style="font-size:13px"><br></span></div><div class="gmail_extra">That's why we have the open bug to fix ld64. Regarding the MC changes though: .alt_entry (a) is the preferred syntax for all MachO developer's that I've talked to, and (b) makes it harder to hit the dangerous corner cases that exist between now and when we fix ld64. Reason (a) seems good enough to support it, reason (b) is just handy.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Lang.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 22, 2016 at 11:25 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> Where would we handle that under your proposal? As far as I know MC doesn't<br>
> have a robust symbolic arithmetic expression evaluator.<br>
<br>
</span>It does. It has to have one. Without one it would be unable to know<br>
what value to write in the symbol table.<br>
<span class=""><br>
> What happens if the<br>
> user types<br>
><br>
> foo:<br>
>         nop<br>
> bar = . + expr_that_evals_to_foo_minus_bar.<br>
><br>
> ?<br>
<br>
</span>Not sure what you mean. You have "bar = expression with bar in it"<br>
which I hope is an error.<br>
<span class=""><br>
> This is no worse than the bug you pointed out, but no better either. The<br>
> real fix for this is to teach ld64 to allow the alt_entry bit on direct<br>
> aliases, then just set it for all alias expressions. I have an internal bug<br>
> filed for that.<br>
<br>
</span>If ld64 cannot handle it than doing this in MC is even more important.<br>
It should be able to get all cases right since it is the one computing<br>
the values of foo and bar it should be able to decide if foo == bar.<br>
Another advantage is that there are no changes to CodeGen and with<br>
that we know that we do the right thing for user written assembly.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div></div>