[llvm] r263521 - [MachO] Add MachO alt-entry directive support.

[Rafael Espíndola via llvm-commits]

On 22 March 2016 at 14:38, Lang Hames <lhames at gmail.com> wrote:
> Hi Rafael,
>
>>> As far as I know MC doesn't have a robust symbolic arithmetic expression
>>> evaluator.
>>
>> It does. It has to have one. Without one it would be unable to know what
>> value to write in the symbol table.
>
>
> The key phrase is robust. We have an arithmetic expression evaluator, but I
> believe it only handles simple expressions.

No. It is truly robust. It is the thing that computes the values of
symbols. There are two cases to consider

* It fails to compute the value of one of the symbols: you get an error anyway.
* It computes both values: it can decide if they are equal.

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

So, what is the expected result in

foo:
nop
bar = . -1

If the desired result is that bar is .alt_entry, then both the current
implementation and the proposed "MCEXpr evaluates to another symbol"
approach should work.

If the expected result is that bar is *not* .alt_entry because it has
the same value as foo than I think you will need to search the symbol
table in MC.

>> If ld64 cannot handle it than doing this in MC is even more important.
>
>
> 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.

Making MC support "foo = expr" is independent of also supporting .alt_entry.

One of the nice things about "foo = expr" is that it is the reliable
way of saying ".alt_entry foo, unless foo is equal to a global symbol
in expr, in which case we cannot use that", which is what you seem to
need for ld64 at the moment.


BTW, with these fixes in place you should be able to change clang to
use constructor aliases:

---------------------------------------------------------------
  // Enable -mconstructor-aliases except on darwin, where we have to work around
  // a linker bug (see <rdar://problem/7651567>), and CUDA device code, where
  // aliases aren't supported.
  if (!getToolChain().getTriple().isOSDarwin() &&
      !getToolChain().getTriple().isNVPTX())
    CmdArgs.push_back("-mconstructor-aliases");
----------------------------------------------------------------


Cheers,
Rafael