Given .globl _f _f: retq .globl _g _g: callq _f retq .subsections_via_symbols llvm-mc notices the two atoms and produces a relocation. Replace "_g:" with "_g = ." and we get none.
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 http://llvm.org/PR19203, 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 '<name> = .'. (Note: This still doesn't fully explain http://llvm.org/PR19203, but that is another instance where labels and 'aliases' behave differently)
(In reply to comment #4) > 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 > '<name> = .'. 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.
(In reply to comment #6) > 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.