Why is that a bug? "_g = ....." basically sets up an alias, but doesn't start a new atom.

The pre-llvm assembler behaves the same way, FWIW.

It means that the linker (and anything else looking at .o files) will have a different idea from the assembler of what the atoms are.

As with #19577 , this matches the cctools as behavior.

My best

Oops. Comment cut off...

My best read of the current semantics matches what Jim said: cctools as (and consequently llvm-mc for MachO) treats named expressions as a separate namespace from regular symbols. That's different from GNU as's view of the world, where regular label definitions can be thought of as sugar for ' = .'.

(Note: This still doesn't fully explain #19577 , but that is another instance where labels and 'aliases' behave differently)

Oops. Comment cut off...

My best read of the current semantics matches what Jim said: cctools as (and
consequently llvm-mc for MachO) treats named expressions as a separate
namespace from regular symbols. That's different from GNU as's view of the
world, where regular label definitions can be thought of as sugar for
' = .'.

That is fine, except that the linker has no idea if one wrote "a:" or "a = .", so the linker and the assembler disagree on what the atoms are.

Now, one way to solve this would be generate SF_AltEntry for "a = ." so that both the linker and assembler would agree that a is not defining an atom.

Oh god - I missed that this was emitting a symbol for _g when it's defined via "_g = .".

Yeah - that's horribly broken when mixed with .subsections_via_symbols. I can use ld -r and an order file to trick _g into calling a different function, without explicitly moving it around.

Given how unsafe it is, I wonder how often '=' is used? Maybe we can warn on it, at least if the RHS contains a symbol.

Oh god - I missed that this was emitting a symbol for _g when it's defined
via "_g = .".

Yeah - that's horribly broken when mixed with .subsections_via_symbols. I
can use ld -r and an order file to trick _g into calling a different
function, without explicitly moving it around.

Given how unsafe it is, I wonder how often '=' is used? Maybe we can warn on
it, at least if the RHS contains a symbol.

Probably not too often, which is why I suggested fixing this by just letting the linker know that _g is not defining an atom.

Fixed in r263521 + r263528.