<div dir="ltr">Hi Rafael,<div><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 the expected result is that bar is *not* .alt_entry because it has<br></span><span style="font-size:13px">the same value as foo than I think you will need to search the symbol<br></span><span style="font-size:13px">table in MC.</span></blockquote><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">This is the desired behavior for now. Recognizing 'label' and '</span>label + C' where C == 0 is a good approximation to it. Where this fails we get an extraneous .alt_entry bit set. I don't believe that is dangerous in practice, but it's not desired output (yet).</div><div><br></div><div>Longer term, I believe the plan is to ensure that ld64 accepts .alt_entry bits on aliases of the form foo = bar, then we can just set the .alt_entry bit wherever we see a non-constant expression.</div><div><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">Making MC support "foo = expr" is independent of also supporting .alt_entry.</span></blockquote><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Certainly.</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">- Lang.</span></div><div><span style="font-size:13px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 12:03 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22 March 2016 at 14:38, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br>
> Hi Rafael,<br>
><br>
>>> As far as I know MC doesn't have a robust symbolic arithmetic expression<br>
>>> evaluator.<br>
>><br>
>> It does. It has to have one. Without one it would be unable to know what<br>
>> value to write in the symbol table.<br>
><br>
><br>
> The key phrase is robust. We have an arithmetic expression evaluator, but I<br>
> believe it only handles simple expressions.<br>
<br>
</span>No. It is truly robust. It is the thing that computes the values of<br>
symbols. There are two cases to consider<br>
<br>
* It fails to compute the value of one of the symbols: you get an error anyway.<br>
* It computes both values: it can decide if they are equal.<br>
<span class=""><br>
> Apologies - the example may not have been clear. The point was that the<br>
> expression didn't have to reference bar, it just had to yield a value that<br>
> was significant. In this example, try substituting any expression at all<br>
> that ultimately evaluates to -1. Assuming this is x86 code, you now have bar<br>
> = foo.<br>
<br>
</span>So, what is the expected result in<br>
<br>
foo:<br>
nop<br>
bar = . -1<br>
<br>
If the desired result is that bar is .alt_entry, then both the current<br>
implementation and the proposed "MCEXpr evaluates to another symbol"<br>
approach should work.<br>
<br>
If the expected result is that bar is *not* .alt_entry because it has<br>
the same value as foo than I think you will need to search the symbol<br>
table in MC.<br>
<span class=""><br>
>> If ld64 cannot handle it than doing this in MC is even more important.<br>
><br>
><br>
> That's why we have the open bug to fix ld64. Regarding the MC changes<br>
> though: .alt_entry (a) is the preferred syntax for all MachO developer's<br>
> that I've talked to, and (b) makes it harder to hit the dangerous corner<br>
> cases that exist between now and when we fix ld64. Reason (a) seems good<br>
> enough to support it, reason (b) is just handy.<br>
<br>
</span>Making MC support "foo = expr" is independent of also supporting .alt_entry.<br>
<br>
One of the nice things about "foo = expr" is that it is the reliable<br>
way of saying ".alt_entry foo, unless foo is equal to a global symbol<br>
in expr, in which case we cannot use that", which is what you seem to<br>
need for ld64 at the moment.<br>
<br>
<br>
BTW, with these fixes in place you should be able to change clang to<br>
use constructor aliases:<br>
<br>
---------------------------------------------------------------<br>
// Enable -mconstructor-aliases except on darwin, where we have to work around<br>
// a linker bug (see <rdar://problem/7651567>), and CUDA device code, where<br>
// aliases aren't supported.<br>
if (!getToolChain().getTriple().isOSDarwin() &&<br>
!getToolChain().getTriple().isNVPTX())<br>
CmdArgs.push_back("-mconstructor-aliases");<br>
----------------------------------------------------------------<br>
<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>