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?
Thanks!
-bw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfstring.diff
Type: application/octet-stream
Size: 2803 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090126/cac0a5c7/attachment.obj>
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. Are you sure the problem is limited to CFStrings? That seems like the wrong thing to be checking somehow.> Thanks! > -bw-------------- next part -------------- A non-text attachment was scrubbed... Name: cfstring.diff Type: application/octet-stream Size: 2803 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090126/11989ac1/attachment.obj> -------------- next part --------------> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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
Hi Bill,> My GCC-fu isn't great. Could someone review this to see if I broke anything?is there no better way?! Is this an objc problem, a darwin problem or...? If it is an objc problem, can't you just have objc set the section on the strings (DECL_SECTION_NAME) when it creates them? Anything but this patch, please! :) Ciao, Duncan.
On Tue, Jan 27, 2009 at 10:56 AM, Duncan Sands <baldrick at free.fr> wrote:> Hi Bill, > >> My GCC-fu isn't great. Could someone review this to see if I broke anything? > > is there no better way?! Is this an objc problem, a darwin problem or...? > If it is an objc problem, can't you just have objc set the section on the > strings (DECL_SECTION_NAME) when it creates them? Anything but this patch, > please! :) >Hi Duncan, There is resistance to this patch, so it's not going in. :-) As I mentioned to Anton, I think that there is a more fundamental problem here. It isn't just Objective-C. I'm going to investigate more. It might be possible to handle this in the back-end (which I would prefer to do). -bw -bw