On Jan 18, 2014, at 10:23 AM, Rafael Espíndola <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
