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

[Lang Hames via llvm-commits]

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.

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.

Not sure what you mean. You have "bar = expression with bar in it"
> which I hope is an error.


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.

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.

- Lang.

On Tue, Mar 22, 2016 at 11:25 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > Where would we handle that under your proposal? 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.
>
> > What happens if the
> > user types
> >
> > foo:
> >         nop
> > bar = . + expr_that_evals_to_foo_minus_bar.
> >
> > ?
>
> Not sure what you mean. You have "bar = expression with bar in it"
> which I hope is an error.
>
> > This is no worse than the bug you pointed out, but no better either. The
> > real fix for this is to teach ld64 to allow the alt_entry bit on direct
> > aliases, then just set it for all alias expressions. I have an internal
> bug
> > filed for that.
>
> If ld64 cannot handle it than doing this in MC is even more important.
> It should be able to get all cases right since it is the one computing
> the values of foo and bar it should be able to decide if foo == bar.
> Another advantage is that there are no changes to CodeGen and with
> that we know that we do the right thing for user written assembly.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160322/964690b0/attachment.html>