.set with an offset inconsistently marked as no-dead-strip on Mach-O

[smeenai]

For the following C code:

int main(int argc, char *argv[]) {
  return argc ? (long)__builtin___CFStringMakeConstantString("foo")
              : (long)__builtin___CFStringMakeConstantString("bar");
}

If we build it with -O3 on top of a Clang which contains #101222 (which enables private globals to be merged), the resulting object file is different if we compile to an object directly vs. if we compile to assembly and then compile that assembly:

$ clang -target arm64-apple-macos11 -O3 -c merge.c
$ llvm-nm -m merge.o | grep l__unnamed_cfstring_.2
0000000000000040 (__DATA,__cfstring) non-external [alt entry] l__unnamed_cfstring_.2

$ clang -target arm64-apple-macos11 -O3 -S -o merge.s merge.c
$ llvm-mc --triple=arm64-apple-macos11 --filetype=obj -o merge2.o merge.s
$ llvm-nm -m merge2.o | grep l__unnamed_cfstring_.2
0000000000000040 (__DATA,__cfstring) non-external [no dead strip] [alt entry] l__unnamed_cfstring_.2

Notice that the symbol is marked as no-dead-strip when built from assembly but not when built from source directly. The reason is that the generated assembly contains the following:

.set l__unnamed_cfstring_.2, __MergedGlobals+32

Which triggers this logic in MC:

llvm-project/llvm/lib/MC/MCParser/AsmParser.cpp

Line 2959 in 907c7eb

Out.emitSymbolAttribute(Sym, MCSA_NoDeadStrip);

If I instead change the line to:

l__unnamed_cfstring_.2 = __MergedGlobals+32

the symbol is not marked as no-dead-strip, which matches the Clang output. It's strange for direct object file emission to not produce the same result as generating assembly and then compiling the assembly; perhaps Clang should be using = instead of .set in its generated assembly? CC @MaskRay

[MaskRay]

the symbol is not marked as no-dead-strip, which matches the Clang output. It's strange for direct object file emission to not produce the same result as generating assembly and then compiling the assembly; perhaps Clang should be using = instead of .set in its generated assembly? CC @MaskRay

The special behavior for .set looks odd. It's from b7b750d (2012).

I agree that perhaps Clang should emit = (without the strange behavior; matches direct object code emission) instead of .set.

Is it feasible to make this opt-in with a cl::opt option? Unfortunately Apple rdar://12219394 is private.

[smeenai]

Thanks for finding the original commit; I was struggling with that. Maybe we can ask someone from Apple if that radar is still relevant? The commit mentions gas compatibility, which I imagine Apple hasn't cared about for a long time, but now there might be places depending on the MC behavior.

That being said, do you think Clang needs a cl::opt for this? I don't think it's very common for end users to use clang -S and then compile the resulting assembly to an object file (vs. just generating the object file directly); I imagine it's mostly compiler developers using that flow, and those developers would probably expect identical results with either flow.

[MaskRay]

Thanks for finding the original commit; I was struggling with that. Maybe we can ask someone from Apple if that radar is still relevant? The commit mentions gas compatibility, which I imagine Apple hasn't cared about for a long time, but now there might be places depending on the MC behavior.

That being said, do you think Clang needs a cl::opt for this? I don't think it's very common for end users to use clang -S and then compile the resulting assembly to an object file (vs. just generating the object file directly); I imagine it's mostly compiler developers using that flow, and those developers would probably expect identical results with either flow.

I agree that we should fix the inconsistent behavior (drop no-dead-strip). I hope we don't add a cl::opt:)

[jyknight]

The odd behavior seems to go back all the way to the initial implementation of -dead_strip for apple's linker and the corresponding assembler changes. The inconsistency between .set and = seems to have been intentional, or, at the least, was documented in that initial implementation.

https://github.com/apple-oss-distributions/cctools/blob/943303b180bfcd833bdc63ebfe3b2ba4448cee37/as/notes#L101

• Added setting the N_NO_DEAD_STRIP bit for .set and assignments for absolute
  symbols. The changes were in read.c in s_equals() and s_set(). Radar bug
  #2284500.

That is, in Apple's assembler, = only set no_dead_strip for absolute symbols, while .set always set it. Presumably this was added as a compatibility hack for some manually-written assembly, since it doesn't otherwise make much sense.

When the behavior was copied into Clang, the "assignments for absolute symbols" part seems to have been missed, and Clang's assembler only implicitly sets no_dead_strip with .set, and not with absolute symbols in =.

It'd seem reasonable to have asm files explicitly write .no_dead_strip SYM when they wanted that, but, I don't know how we might determine whether any hand-written assembly files still require this hack, and thus whether it's safe to drop the no_dead_strip behavior from .set, now.

Switching LLVM to emit = for MCAsmStreamer::emitAssignment on Mach-O platforms sounds like a safer fix.

[MaskRay]

https://reviews.llvm.org/D44256 (for Hexagon) switched MCAsmStreamer from = to .set. We should reverse the change and prefer =.