Hi all, int main() { t(""); return 0; } On Mac OS X, llvm-gcc compiles the zero-sized string to: .lcomm LC,1,0 gcc: .cstring LC0: .ascii "\0" The difference seems innocent enough. However, in objc if the zero- sized string is part of a cfstring, it causes a problem. The linker expects it in the readonly __cstring section, but llvm puts it in the read / write bss section. The problem is llvm represents this as @"\01LC" = internal constant [1 x i8] zeroinitializer CodeGen can tell it should go into a read only section, but it cannot know it's a cstring. Any ideas how I can fix this? If I write the zero- sized string as c"A\00", bitcode reader still turns it back to zeroinitializer. Thanks, Evan
On Fri, Jan 9, 2009 at 5:40 PM, Evan Cheng <evan.cheng at apple.com> wrote:> The difference seems innocent enough. However, in objc if the zero- > sized string is part of a cfstring, it causes a problem. The linker > expects it in the readonly __cstring section, but llvm puts it in the > read / write bss section.That seems extremely weird... what sort of magic is objc using that could possibly care where a string is stored? Can you give a more complete testcase? It sounds like LLVM isn't modelling something which it really should be...> The problem is llvm represents this as > > @"\01LC" = internal constant [1 x i8] zeroinitializer > > CodeGen can tell it should go into a read only section, but it cannot > know it's a cstring. Any ideas how I can fix this? If I write the zero- > sized string as c"A\00", bitcode reader still turns it back to > zeroinitializer.LangRef claims that you can specify a section for globals, although I can't actually manage to get it to work... -Eli
On Jan 10, 2009, at 1:21 AM, Eli Friedman wrote:> On Fri, Jan 9, 2009 at 5:40 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> The difference seems innocent enough. However, in objc if the zero- >> sized string is part of a cfstring, it causes a problem. The linker >> expects it in the readonly __cstring section, but llvm puts it in the >> read / write bss section. > > That seems extremely weird... what sort of magic is objc using that > could possibly care where a string is stored? Can you give a more > complete testcase? It sounds like LLVM isn't modelling something > which it really should be... >The runtime probably has various requirements about this.>> The problem is llvm represents this as >> >> @"\01LC" = internal constant [1 x i8] zeroinitializer >> >> CodeGen can tell it should go into a read only section, but it cannot >> know it's a cstring. Any ideas how I can fix this? If I write the >> zero- >> sized string as c"A\00", bitcode reader still turns it back to >> zeroinitializer. > > LangRef claims that you can specify a section for globals, although I > can't actually manage to get it to work... >We normally specify the sections in the config/darwin.c file for various special kinds of OBJC names (see darwin_objc_llvm_special_name_section()). Perhaps we could do the same for this? Obviously, it's not a special name, but if we could tag the global with the correct section then perhaps all will be well. -bw
Reasonably Related Threads
- [LLVMdev] How to represent zero-sized string?
- [LLVMdev] RFC: -fwritable-strings Change
- [LLVMdev] (Not) instrumenting global string literals that end up in .cstrings on Mac
- [LLVMdev] RFC: -fwritable-strings Change
- [LLVMdev] (Not) instrumenting global string literals that end up in .cstrings on Mac