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

[Lang Hames via llvm-commits]

Hi Rafael,

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.


This is the desired behavior for now. Recognizing 'label' and '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).

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.

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


Certainly.

- Lang.


On Tue, Mar 22, 2016 at 12:03 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160322/3c4fbb55/attachment.html>