[llvm] [MachO] Preserve weak aliases and fix alias n_desc flags (PR #212001)

[Damian Malarczyk via llvm-commits]

dmcyk wrote:

I'm on the linker team at Apple. I can share some more context about MachO, but I'll refrain from advising on the implementation details in clang/llvm.
MachO has no explicit concept of aliases. There's a limited support, where you can define an alias to a symbol *not* defined in your local TU, to import it under a different name, but that's not the use case here.

For defined symbols, you can place multiple symbol labels at the same address, and ld will treat one as an alias of the other. ld will choose one deterministically, but there's no way to specify if it's 'foo is an alias of bar' or vice versa.
In practice, there is no difference if both alias and its target are *strong* definitions, but there's a difference if either is weak.

> The LLD MachO test suite specifically tests for weak aliases https://github.com/llvm/llvm-project/blob/main/lld/test/MachO/weak-alias-override.s which is at least a strong signal that weak aliases should be supported.

That test case has been added only recently. There's an issue related to this in https://github.com/llvm/llvm-project/issues/167262 that observed a difference when using Apple's linkers and the `-ld-classic` option. But it's never been supported with `-ld-classic` either. The behavior you'd see today having a weak and a strong definition labels at the same address depends on the name of those labels, but you'll only see it once you attempt to override the weak definitions.

As of Xcode 27 beta 5, we've made this more predictable, where if you have both weak and strong symbol label at the same address, the strong label will be selected as a definition and weak-def will be treated as its alias. However, if you have multiple weak-definitions and no strong definition at the same address, you'll end up with the same issues as covered in #167262.

i.e., only as of Xcode 27 weak-aliases in MachO can be reliably supported, but with the constraints that the aliasee is defined in the same TU *and* is a strong definition.


As for the LLM generated table about other attributes, I have a few remarks,

> N_WEAK_DEF Weak definition; the symbol definition can be overridden by another strong definition

There might be some source backwards compatibility problems with that. in llvm's assembler today if you specify `.weak_definition _foo`  and have `.set _bar,_foo` , _bar will also get the `weak-def` flag. whereas `.weak_definition _bar` will get ignored, if `_foo` doesn't have it.
ie., I think this would have been correct, but there might be some compatibility issues and since Apple's ld does not support strong aliases to weak definitions, you could preserve the existing behavior, but do allow `.weak_definition` being independently used on `.set` symbols.

> N_ALT_ENTRY Alternate entry point; indicates that this symbol is an alternate entry point

If aliassee has an alt entry bit, then alias must have it as well. Otherwise the alias will be treated as a separate definition and it'll be inverted, where aliassee becomes an alias instead.

> N_NO_DEAD_STRIP Prevents the linker from dead-stripping this symbol

That’s alright, although FYI today already if aliassee has no-dead-strip flag, then alias will be kept as well.

> N_COLD_FUNC Cold function; indicates code layout/hotness information

alias can't be ordered independently from aliassee in the binary, so aliassee will always drive it whether set or not.

> N_SYMBOL_RESOLVER Symbol resolver; indicates the function at this address is a resolver

Similar here. This is something our linker handles already. If the aliassee has the resolver flag, then the alias is treated as a resolver as well.

> REFERENCE_TYPE

I'm not sure about this one. Suppose it's some legacy thing. Neither ld-classic nor ld use this.

I'd suggest adding explicit test cases for each of those scenarios.

https://github.com/llvm/llvm-project/pull/212001