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

[Lang Hames via llvm-commits]

Hi Rafael,

But it does so in the wrong place. It doesn't handle things like A +
> expr_that_evaluates_to_zero.
>

Where would we handle that under your proposal? As far as I know MC doesn't
have a robust symbolic arithmetic expression evaluator. What happens if the
user types

foo:
        nop
bar = . + expr_that_evals_to_foo_minus_bar.

?

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.

In the mean time, using .alt_entry at least guarantees that the resulting
expression is of the form 'Label + C' which can be easily recognized.

ideally you would avoid MC even creating new fragments. To do that, what is
> needed
> is to add the restriction that ".alt_entry foo" comes  before "foo:".


Agreed. I'll figure out how to add that.

- Lang.

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

> On 22 March 2016 at 11:20, Lang Hames <lhames at gmail.com> wrote:
> > Hi Rafael,
> >
> > Apologies - mis-hit the send button. Continuing on...
> >
> > My patch special-cased 'foo + 0' to behave the same as 'foo' - ld64
> > recognizes aliases for the same location and treats them as one atom. We
> > only need to set the alt_entry bit on 'foo + C', where C is non-zero.
>
> But it does so in the wrong place. It doesn't handle things like A +
> expr_that_evaluates_to_zero.
>
> Codegen can just print
>
> sym = expr
>
> and let MC do the work. If expr is zero, no need to output the flag.
> If non-zero, emit the flag.
>
> >> As noted in the review this introduces a different bug with regards to
> >> ld and llvm-mc not agreeing about which symbols are atoms.
> >
> >
> > This is unfortunate, but the new bug is benign: at worst you get
> redundant
> > relocations. With a bit of work in MC I can probably get rid of these
> too.
> > The old bug was much more dangerous - you could end up with code that
> needed
> > relocations and didn't have any.
>
> It is still somewhat dangerous bug as people can become dependent on
> it. Avoiding the relocation shouldn't be too hard, but ideally you
> would avoid MC even creating new fragments. To do that, what is needed
> is to add the restriction that ".alt_entry foo" comes  before "foo:".
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160322/f0ae1b0f/attachment.html>