[cfe-commits] r127594 - in /cfe/trunk: lib/CodeGen/CodeGenModule.cpp test/CodeGen/darwin-string-literals.c

[Rafael Espíndola]

>> Perhaps the linkage change is just really blocking the string data from getting merged and moved to another section?
>
> Unlikely. I don't think we ever try to merge a string with something else.

Looks like this is exactly what is going on. I was able to reproduce
the crash even with current llvm, clang and ld64. The issue is that
given a c++ file with

extern const char js_name_str[] = "name";

we notice that the address might be significant and produce

@js_name_str = constant [5 x i8] c"name\00", align 1

at codegen time this becomes:

.section __TEXT,__const
.globl _js_name_str            ## @js_name_str
_js_name_str:
.asciz "name"

But given a .mm file with

[notification valueForKey:@"name"];

We notice that the address is *not* significant and produce

@.str = linker_private unnamed_addr constant [5 x i8] c"name\00", align 1

at codegen time this becomes

.section __TEXT,__cstring,cstring_literals
l_.str:                                 ## @.str
.asciz "name"

Note how the unnamed_addr causes us to use __cstring. Now, if we LTO,
llvm will merge the @.str and the @js_name_str. The resulting string
has a significant address and goes to __const. I assume ld64 then
asserts because it cannot find the string it wants in __cstring.

It would be nice for ld64 to support this, but I think the issue can
reliably be avoided by adding an explicit  section
"__TEXT,__cstring,cstring_literals" to the IR for strings used from
objc. I will give that a try.

Cheers,
Rafael