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

Lang Hames via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 7 15:05:42 PDT 2016


Hi Rafael,

I'm finally getting back to this.

Now you get a crash when using .alt_entry on non MachO. It should be
> an error. That is, you should not be parsing this in generic code,
> only on MachO specific code.


Do you have a test-case that crashes on non-MachO? The trivial cases I
tried were silently accepted.

I'm going to make any use of .alt_entry on other formats an error anyway,
but I'd like to make sure I understand any crashes first.

- Lang.


On Tue, Mar 15, 2016 at 10:40 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> I don't think this was ready for commit.
>
> Why was it decided that the .alt_entry syntax was needed?
>
> > +
> > +    if (MAI->hasAltEntry() && isa<MCBinaryExpr>(Expr))
> > +      OutStreamer->EmitSymbolAttribute(Name, MCSA_AltEntry);
> > +
>
> I think this is a odd. You are handling "foo" and "foo + 0"
> differently. Given what you handle "a = ..." in MC, why do you need to
> change codegen at all?
>
> >    DirectiveKindMap[".symbol_resolver"] = DK_SYMBOL_RESOLVER;
> > +  DirectiveKindMap[".alt_entry"] = DK_ALT_ENTRY;
> >    DirectiveKindMap[".private_extern"] = DK_PRIVATE_EXTERN;
> >    DirectiveKindMap[".reference"] = DK_REFERENCE;
> >    DirectiveKindMap[".weak_definition"] = DK_WEAK_DEFINITION;
>
> Now you get a crash when using .alt_entry on non MachO. It should be
> an error. That is, you should not be parsing this in generic code,
> only on MachO specific code.
>
> Probably most importantly:
>
> As noted in the review this introduces a different bug with regards to
> ld and llvm-mc not agreeing about which symbols are atoms. Given
>
> bar:
>         .alt_entry foo
> foo:
> call bar
>
> llvm-mc produces a relocation. Given
>
> bar:
> foo = .
> call bar
>
> we get no relocation. In both cases the linker thinks foo is not an atom.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160407/88684241/attachment.html>


More information about the llvm-commits mailing list