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