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

[Rafael Espíndola]

>> both "foo" and "bar" get put in __TEXT,__cstring,cstring_literals, but
>> with different symbol styles:
>>
>> L_.str:
>>        .asciz  "foo"
>> l_.str1:
>>        .asciz  "bar"
>>
>> Why does the linker need a visible symbol for "bar"? Doesn't an offset
>> into the section tells it all that it needs to know: this relocations
>> points to the string "bar”.
>
> Using an ‘L’ label for “bar” should be fine (when it is in the __cstring section).
>
> The known linker problem with CFString literals is that the linker coalesces them (the freeze dried CF objects) and to do so, it needs to understand what the “backing store” data is to compare it.  The linker only handles CFString objects with a backing store in the __cstring (UTF8 encoding) or _ustring (for UTF16 encoding).  If the compiler decides to be clever and merge the backing store data with something else and put it into the say, __const section, the linker will assert that the CFString object is malformed.
>
> 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.

Thanks for mentioning utf16. I see that the code in clang has a fixit
for it too:

    // FIXME: why do utf strings get "_" labels instead of "L" labels?
    Linkage = llvm::GlobalValue::InternalLinkage;

I will try a patch fixing both FIXMEs and send for review if it works.

Thanks,
Rafael