[LLVMdev] RFC: -fwritable-strings Change

[Bill Wendling]

On Mon, Jan 26, 2009 at 4:45 PM, Dale Johannesen <dalej at apple.com> wrote:
>
> On Jan 26, 2009, at 4:07 PMPST, Bill Wendling wrote:
>
>> There is a problem with Objective-C code where a null string is placed
>> in the wrong section. If we have this code:
>>
>> #include <Foundation/Foundation.h>
>> void foo() {
>>  NSLog(@"");
>> }
>>
>> The null string is defined like this:
>>
>>        .const
>>        .lcomm  LC,1,0          ## LC
>>
>> Causing our linker to go nuts, because it expects anonymous strings to
>> be in the __cstring section. I came up with the attached patch, which
>> places the string in the .cstring section.
>>
>> My GCC-fu isn't great. Could someone review this to see if I broke
>> anything?
>
> I don't see anything obvious wrong, but this is an easy area to break.
> I'd recommend running the gcc testsuite and checking for regressions.
>
Okay, that's a good plan.

> Are you sure the problem is limited to CFStrings?  That seems like the wrong
> thing to be checking somehow.
>
Nick Kledzik had this to say about the initial radar (<rdar://problem/6479858>):

"1/7/09 11:15 PM Nick Kledzik:
The linker issues this warning when the .o file contains a literal
NSString (e.g. @"hello") and the bytes (usually utf8) that the object
pointers to are not an anonymous string in the __cstring section."

And later:

"1/8/09 10:37 PM Nick Kledzik:
I traced this down to an llvm bug with zero length constant CF
strings. Here is a simple example:

[/tmp]> cat foo.m
#include <Foundation/Foundation.h>
void foo() {
  NSLog(@"");
}

[/tmp]>  /Developer/usr/bin/llvm-gcc-4.2 foo.m -arch x86_64 -Os -S
[/tmp]> cat foo.s
...
L_unnamed_cfstring_0:                           ## L_unnamed_cfstring_0
        .quad   ___CFConstantStringClassReference
        .long   1992                    ## 0x7C8
        .space  4
        .quad   LC
        .space  8
        .const

        .lcomm  LC,1,0          ## LC
...
[/tmp]>

The bug is that LC1 should be a read-only zero byte in the cstring
section.  The compiler is making this a r/w zero byte in the bss
section."

I initially took this to mean that it's an Objective-C only problem.
Writing a simple test program, it looks like GCC puts the null string
in the ".cstring " section even for non-CFStrings. So the problem may
be more extensive than I first thought.

-bw