search for: __cstring

...sManagerERNS_7PMStackENS_15PassManagerTypeE 00000001004223d0 (__TEXT,__text) weak external __ZN4llvm4Pass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeE 0000000100262120 (__TEXT,__text) external __ZN4llvm8LoopPass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeE 00000001004d7936 (__TEXT,__cstring) non-external __ZZN4llvm10ModulePass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeEE8__func__ 00000001004bcf42 (__TEXT,__cstring) non-external __ZZN4llvm10RegionPass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeEE8__func__ 00000001004d7924 (__TEXT,__cstring) non-external __ZZN4llvm12F...

...15PassManagerTypeE > 00000001004223d0 (__TEXT,__text) weak external > __ZN4llvm4Pass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeE > 0000000100262120 (__TEXT,__text) external > __ZN4llvm8LoopPass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeE > 00000001004d7936 (__TEXT,__cstring) non-external > __ZZN4llvm10ModulePass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeEE8__func__ > 00000001004bcf42 (__TEXT,__cstring) non-external > __ZZN4llvm10RegionPass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeEE8__func__ > 00000001004d7924 (__TEXT,__cstring) non-ex...

Alexander, On Darwin the "__cstring" section (really section with type S_CSTRING_LITERAL) is defined to contain zero terminate strings of bytes that the linker can merge and re-order. If you want pad bytes before and after the string, you need to put the strings in a different section (e.g. __TEXT, __const). But, CF/NSString l...

(forgot to CC llvmdev) On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at google.com> wrote: > Hey Anna, Nick, Ted, > > We've the following problem with string literals under ASan on Mac. > Some global string constants end up being put into the .cstring > section, for which the following rules apply: > - the strings can't contain zeroes in their

...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: applica...

...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...

...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 t...

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......

...struct._mulle_objc_loadclasslist*, %struct._mulle_objc_loadcategorylist*, %struct._mulle_objc_superlist*, %struct._mulle_objc_loadcategorylist.0*, %struct._mulle_objc_loadhashnamelist* } @OBJC_METH_VAR_NAME_ = private unnamed_addr constant [8 x i8] c"test1::\00", section "__TEXT,__cstring,cstring_literals", align 1 @OBJC_METH_VAR_TYPE_ = private unnamed_addr constant [16 x i8] c"v32 at 0:8^v16^v24\00", section "__TEXT,__cstring,cstring_literals", align 1 @OBJC_CLASS_NAME_ = private unnamed_addr constant [4 x i8] c"Foo\00", section "__TEXT,__...

On Mon, Mar 2, 2009 at 2:45 PM, Jonathan Turner <probata at hotmail.com> wrote: > For which version of gcc?  I should mention I'm on OS X and using the LLVM > SVN. gcc 4.3. It's also possible this is processor-sensitive. >> First, try looking at the generated code... the code LLVM generates is >> probably not what you're expecting. I'm getting the

...; 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. >...

...cmove %edx, %eax incl %ecx cmpl $999999999, %ecx jne LBB1_1 ## loopto LBB1_2: ## bb1 movl %eax, 4(%esp) movl $LC, (%esp) call _printf xorl %eax, %eax addl $12, %esp ret .section __TEXT,__cstring,cstring_literals LC: ## LC .asciz "Timeout: %i\n" .subsections_via_symbols Setting the loops to decl instead of cmove/incl might seem like more work, but appears to be faster: .text .align 4,0x90 .globl _main _ma...

> Date: Mon, 2 Mar 2009 13:41:45 -0800 > From: eli.friedman at gmail.com > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Tight overlapping loops and performance > > Hmm, on my computer, I get around 2.5 seconds with both gcc -O3 and > llvm-gcc -O3 (using llvm-gcc from svn). Not sure what you're doing > differently; I wouldn't be surprised if it's

...on (__DWARF, __debug_pubtypes): 32449 | Section (__DWARF, __debug_str): 17541 | Section (__DWARF, __debug_str): 0 Section (__DWARF, __debug_ranges): 456 | Section (__DWARF, __debug_ranges): 0 Section (__DATA, __const): 100 | Section (__DATA, __const): 136 Section (__TEXT, __cstring): 11543 | Section (__TEXT, __cstring): 12678 Section (__DATA, __data): 64 | Section (__DATA, __data): 76 Section (__DATA, __const_coal): 48 | Section (__TEXT, __const_coal): 128 | Section (__DATA, __mod_init_func): 4 | Section (__DATA, __mod_init_func): 4 Section (_...

..._cfa_offset 16 > movl _main-4(%rip), %esi > leaq L_.str(%rip), %rdi > xorl %eax, %eax > callq _printf > xorl %eax, %eax > popq %rcx > retq > .cfi_endproc > > .section __TEXT,__cstring,cstring_literals > L_.str: ## @.str > .asciz "p = %d\n" > > > .globl _main.dsp > .alt_entry _main.dsp > _main.dsp = _main-4 > .subsections_via_symbols > > any ideas how to get the .alt_entry right...

...of longish."); } $ gcc -arch i386 -S -o - t.c -Os .cstring .align 2 LC0: .ascii "this is some error message that is kind of longish.\0" ... LLVM on the other hand generates this on Darwin: $ /Developer/usr/bin/llvm-gcc -arch i386 -S -o - t.c -Os ... .section __TEXT,__cstring,cstring_literals .align 4 LC: .asciz "this is some error message that is kind of longish." Note that the alignment in LLVM is greater than it is for GCC. When I look at the alignment of the string in GDB, the front-end is saying that it's 8, which would be '.ali...

...some code that calls an Objective-C method. As far as I understand the object file is supposed to contain a section __message_refs, in the __OBJC segment. This section contains pointers to C strings, which contain the names of the Objective-C selectors (methods). The C strings are stored in the __cstring __TEXT section and segment. As far as I can see the these sections looks to have the correct flags and contents. The problem is I'm getting an assertion in the linker: http://www.opensource.apple.com/source/ld64/ld64-134.9/src/ld/parsers/macho_relocatable_file.cpp Line 5024, in Objc1ClassR...

...eSectionSwitch("__TEXT", "__const"); - if (IDVal == ".static_const") - return ParseDirectiveSectionSwitch("__TEXT", "__static_const"); - if (IDVal == ".cstring") - return ParseDirectiveSectionSwitch("__TEXT","__cstring", - MCSectionMachO::S_CSTRING_LITERALS); - if (IDVal == ".literal4") - return ParseDirectiveSectionSwitch("__TEXT", "__literal4", - MCSectionMachO::S_4BYTE_LITERALS, -...

...rip), %esi > > leaq L_.str(%rip), %rdi > > xorl %eax, %eax > > callq _printf > > xorl %eax, %eax > > popq %rcx > > retq > > .cfi_endproc > > > > .section __TEXT,__cstring,cstring_literals > > L_.str: ## @.str > > .asciz "p = %d\n" > > > > > > .globl _main.dsp > > .alt_entry _main.dsp > > _main.dsp = _main-4 > > .subsections_via_symbols > > &...

On Mon, Mar 6, 2017 at 5:54 PM, Moritz Angermann <moritz.angermann at gmail.com > wrote: > Hi Peter, > > I’ve just experimented with this a bit: > > Say we would end up with the following assembly: > > .section __TEXT,__text > .globl _main > > .long 1 > _main: > inc %eax > ret > > .globl _main.dsp > .alt_entry _main.dsp