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

[Nick Kledzik]

On Dec 11, 2013, at 2:21 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> On 14 March 2011 14:37, Chris Lattner <clattner at apple.com> wrote:
>> 
>> On Mar 14, 2011, at 10:55 AM, Rafael Espindola wrote:
>> 
>>> Author: rafael
>>> Date: Mon Mar 14 12:55:00 2011
>>> New Revision: 127594
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=127594&view=rev
>>> Log:
>>> Fix link of libxul with LTO and the linker in xcode4. It is not clear if this
>>> is working around a bug in ld or if the new linker has a reasonable reason
>>> for wanting the string constant to be linker visible.
>> 
>> Hi Rafael,
>> 
>> Private is probably the wrong answer, but I think that LinkerPrivate is the right answer.  Does LinkerPrivate work for libxul?
> 
> Bringing up an old thread now that I know Nick's email :-)
> 
> Nick, can you confirm if this a real requirement by the linker of if
> it was a bug in that version? The issue is that given
> 
> const char *foo() {
>  return "foo";
> }
> const void *bar() {
>  return __builtin___CFStringMakeConstantString("bar");
> }
> 
> 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?

-Nick