>> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
