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

[Lang Hames via llvm-commits]

Never mind - turns out I was just using a stale clang. I see the crash now.
I'll start looking in to it.

- Lang.

On Thu, Apr 7, 2016 at 3:05 PM, Lang Hames <lhames at gmail.com> wrote:

> 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/94bfa78d/attachment.html>