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

[Nick Kledzik]

On Jan 18, 2014, at 10:23 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>>> 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.
This was improved in ld64-234.  

The linker tries to merge NS/CFString objects in case two files each use the same @“” string.  
But to merge the objects the linker must know what string they point to.  Currently, NS/CFString 
objects can point to UTF8 strings in __cstring or UTF16 strings in __ustring section.
When the linker saw a NS/CFString object point to a string in some other section, it would 
assert.  The recent improvement was to have the linker just consider the NS/CFString to 
be unmergable in that case.

-Nick



> 
> 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