search for: cfstring

...07fff8a12f0ad -[NSObject(NSObject) doesNotRecognizeSelector:] + 205 3 CoreFoundation 0x00007fff8a074e24 ___forwarding___ + 1028 4 CoreFoundation 0x00007fff8a074998 _CF_forwarding_prep_0 + 120 5 CoreFoundation 0x00007fff89ffd11d CFStringGetCString + 173 6 macosx-ups 0x0000000104158ebb upsdrv_initups + 409 7 macosx-ups 0x0000000104159bd2 main + 1040 8 libdyld.dylib 0x00007fff9083e5c9 start + 1 ) libc++abi.dylib: terminating with uncaught exception of ty...

...ectly. 0.000000 debug level is '4' 0.000233 upsdrv_initups(): Power Sources blob: <CFArray 0x7ffd18605480 [0x7fff7443bed0]>{type = immutable, count = 1, values = ( 0 : <CFBasicHash 0x7ffd18605360 [0x7fff7443bed0]>{type = immutable dict, count = 10, entries => 0 : <CFString 0x7ffd18605800 [0x7fff7443bed0]>{contents = "Voltage"} = <CFNumber 0x4c9037 [0x7fff7443bed0]>{value = +19600, type = kCFNumberSInt64Type} 1 : <CFString 0x7ffd18605820 [0x7fff7443bed0]>{contents = "Power Source ID"} = <CFNumber 0x37 [0x7fff7443bed0]>{value =...

On Jun 27, 2015, at 9:17 AM, Charles Lepple <clepple at gmail.com> wrote: > On Jun 26, 2015, at 11:07 PM, Sundeep Mediratta <smedius at gmail.com> wrote: > >> 0.000233 upsdrv_initups(): Power Sources blob: >> <CFArray 0x7ffd18605480 [0x7fff7443bed0]>{type = immutable, count = 1, values = ( >> 0 : <CFBasicHash 0x7ffd18605360 [0x7fff7443bed0]>{type

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

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

...s 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 literals will be problematic. The compiler emits a static NS/CFString object into a data section. That object contains a pointer to its "backing" utf8 or utf16 string literal. The linker coalesce the NS/CFString objects (so that two translation units that define @"hello" will wind up using the same object). But to tell if two CF/NSString object...

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

Hi all, Right now the Mangler::getValueName() method will produce something like "__unnamed_1_37" for a global value that doesn't have a name. This is wrong for Objective-C where CFStrings will get these labels, thus preventing the linker from coalescing them. [/tmp]> nm -s __DATA __cfstring -m foo.o 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 ... I think that prepending the PrivateGlobalPrefi...

(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

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

...that solve the problem? Dan On Nov 23, 2008, at 2:15 AM, Bill Wendling wrote: > Hi all, > > Right now the Mangler::getValueName() method will produce something > like "__unnamed_1_37" for a global value that doesn't have a name. > This is wrong for Objective-C where CFStrings will get these labels, > thus preventing the linker from coalescing them. > > [/tmp]> nm -s __DATA __cfstring -m foo.o > 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 > 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 > ... > > I think th...

...column -fsplit-ivs-in-unroller # -ftoplevel-reorder -ftree-loop-im -ftree-loop-ivcanon # -ftree-loop-optimize -ftree-vect-loop-version -funit-at-a-time # -fverbose-asm -fzero-initialized-in-bss -m128bit-long-double -m32 -m80387 # -maccumulate-outgoing-args -malign-stringops -matt-stubs # -mconstant-cfstrings -mfancy-math-387 -mfp-ret-in-387 -mieee-fp -mmmx # -mno-red-zone -mno-sse4 -mpush-args -msse -msse2 -msse3 # -mwarn-nonportable-cfstrings # Compiler executable checksum: 8b71d7bb9d5d18146938b09f1ac40213 from... touch t.cc llvm-gcc-4 -fverbose-asm t.cc -S

...ce for the samba components in MacOS X Server is located at: http://www.opensource.apple.com/tools/cvs ('samba' module) The latest vendor branch is samba2.2.1a. The main branch includes the following modifications (see diffs below).. 1) DirectoryService suport (encrypted authentication) 2) CFString usage (DOS code page <-> decomposed UTF8) 3) smbstatus -r (raw dump of user connections) You may forward questions regarding MacOS X Server system services (e.g. DirectoryService) to the following mailing list.. http://lists.apple.com/mailman/listinfo/macos-x-server Index: source/Makefile...

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

...; > On Nov 23, 2008, at 2:15 AM, Bill Wendling wrote: > >> Hi all, >> >> Right now the Mangler::getValueName() method will produce something >> like "__unnamed_1_37" for a global value that doesn't have a name. >> This is wrong for Objective-C where CFStrings will get these labels, >> thus preventing the linker from coalescing them. >> >> [/tmp]> nm -s __DATA __cfstring -m foo.o >> 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 >> 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 >>...

On Nov 24, 2008, at 11:07 AM, Chris Lattner wrote: > > On Nov 24, 2008, at 11:01 AM, Bill Wendling wrote: > >> The symbols I'm interested in already have internal linkage (as you >> would expect). But because the mangler is in charge of assigning them >> names, they never seem to be decorated with the 'L' in front. . . . > > If you use

...problems. I added code to substitute colons for slashes > inside fsreffrompath() in lib/sysxattrs.c > > I hesitate to provide a patch because I am really unsure if I did it > well. I copy the filename to a temporary string, do the substitution > and then pass the temp string to CFStringCreateWithCString(). I > think a better approach would be to scrap my changes and do the > substitution on the buffer returned by CFStringGetCharacters(), > before FSMakeFSRefUnicode is called. This would get rid of the new > memory allocation. > > But I am unsure how to do...