[PATCH] D17854: add .alt_entry assembly directive for Mach-O

[Bob Wilson via llvm-commits]

> On Mar 3, 2016, at 12:31 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> On 3 March 2016 at 15:20, Bob Wilson <bob.wilson at apple.com> wrote:
>> bob.wilson added a comment.
>> 
>> The object files have a new SF_AltEntry flag to distinguish symbols that do not start a new atom. ld64 has had support for that for a while now.
> 
> OK, so the idea is that the
> 
> .alt_entry foo
> 
> directive causes foo to have the SF_AltEntry flag which tells the
> linker that foo doesn't define an atom.
> 
> Another possibility would be to close pr25381 as working as intended and have
> 
> foo = bar
> and
> foo = bar + 42
> 
> not start new atoms and produce SF_AltEntry (maybe dropping it for
> offset 0 as an optimization).
> 
> This would have the advantage of not needing a new directive and
> avoiding having to diagnose things like
> 
> foo:
> .alt_entry foo

I’m open to that. I checked with the Swift team, and they’re generating global aliases in IR without relying on the assembly syntax.

+ Nick, Lang, and Louis
Do you have an opinion on this from the linker’s perspective?

Here’s a test that Akira wrote for the assembly-to-object part.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: altent.s
Type: application/octet-stream
Size: 1005 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160303/c0b3eb95/attachment.obj>