similar to: [LLVMdev] RFC: -fwritable-strings Change

Displaying 20 results from an estimated 700 matches similar to: "[LLVMdev] RFC: -fwritable-strings Change"

2009 Jan 27
0
[LLVMdev] RFC: -fwritable-strings Change
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
2009 Jan 27
2
[LLVMdev] RFC: -fwritable-strings Change
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(@"");
2009 Jan 10
2
[LLVMdev] How to represent zero-sized string?
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
2009 Jan 27
0
[LLVMdev] RFC: -fwritable-strings Change
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.
2013 Mar 21
2
[LLVMdev] (Not) instrumenting global string literals that end up in .cstrings on Mac
(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
2013 Mar 21
0
[LLVMdev] (Not) instrumenting global string literals that end up in .cstrings on Mac
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 literals will be problematic. The compiler emits a static
2009 Jan 10
0
[LLVMdev] How to represent zero-sized string?
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
2011 Jul 20
2
[LLVMdev] MC ARM ELF local common variable alignment.
Hi all, I noticed that the static local variable(internal global in .bc) is not aligned in ARM ELF(use MC(-filetype=obj)). Then I found that the alignment information is lost at: lib/CodeGen/AsmPrinter/AsmPrinter.cpp:316 if (MAI->hasLCOMMDirective()) { // .lcomm _foo, 42 OutStreamer.EmitLocalCommonSymbol(GVSym, Size); return; } MCStreamer::EmitLocalCommonSymbol have
2011 Jul 20
0
[LLVMdev] MC ARM ELF local common variable alignment.
Hi, Can you please file a bug and Cc me directly on it? I'll go take a look soon. Thanks -jason On Wed, Jul 20, 2011 at 9:53 AM, TDYa127 <a127a127 at gmail.com> wrote: > Hi all, > > I noticed that the static local variable(internal global in .bc) is > not aligned in ARM ELF(use MC(-filetype=obj)). > Then I found that the alignment information is lost at: >
2009 Jan 27
0
[LLVMdev] RFC: -fwritable-strings Change
Hello, Bill >> >> 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. I'm strongly agains any target-specific and language-specific hacks in the generic tree-conversion code. What if we decide to support objc on
2009 Jan 27
0
[LLVMdev] RFC: -fwritable-strings Change
Hello, Bill > I should have put this in darwin.h and called it from there. I think > that there is a far more fundamental problem that affects more than > Objective-C. Even with C code, we place a null string in a writable > section, which isn't correct. I've attached the .bc file. The culprit > is the @"\01LC" global. (This is generated with my hack, so it has an
2009 Jan 28
0
[LLVMdev] RFC: -fwritable-strings Change
On Tue, Jan 27, 2009 at 1:35 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Tue, Jan 27, 2009 at 1:15 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > But if we place a null string in a > writable section and we don't have "writable strings" enabled, then, > well, it's in a writable section when it shouldn't be. If writable strings are
2009 Jan 27
0
[LLVMdev] RFC: -fwritable-strings Change
On Tue, Jan 27, 2009 at 1:00 PM, Bill Wendling <isanbard at gmail.com> wrote: > Even with C code, we place a null string in a writable > section, which isn't correct. You could say that, but it's not really wrong... say you had a 10 kilobyte struct that was all null. If you put it into a data section, it takes up 10k in the executable (unless Darwin has some unusual data
2009 Jan 27
2
[LLVMdev] RFC: -fwritable-strings Change
On Tue, Jan 27, 2009 at 1:15 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jan 27, 2009 at 1:00 PM, Bill Wendling <isanbard at gmail.com> wrote: >> Even with C code, we place a null string in a writable >> section, which isn't correct. > > You could say that, but it's not really wrong... say you had a 10 > kilobyte struct that was all
2009 Jan 27
4
[LLVMdev] RFC: -fwritable-strings Change
On Tue, Jan 27, 2009 at 9:06 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > I'm strongly agains any target-specific and language-specific hacks in the > generic tree-conversion code. What if we decide to support objc on > non-darwin platforms someday? > This is theoretically possible (well, modulo all bunch of apple-local stuff > arond ;)). > > I
2013 Jan 30
0
[LLVMdev] Calling dispatch_async() within call to ExecutionEngine::runFunction()
I have used libdispatch (on FreeBSD) from JIT'd code without any issues, so I think your bug is elsewhere. David On 30 Jan 2013, at 07:43, Rick Mann wrote: > My host app calls runFunction() on my JITed code. It, in turn, calls a C function ("decode()") in the host app that then calls dispatch_async(). The runFunction() call returns as expected, but the block passed to
2011 Jun 02
1
Any tips for speeding up encoding on iPhone?
Hi, I'm trying to use Speex for real time encoding in an iPhone project but I'm having latency problems. I appreciate any tips you may provide for speeding things up. The recording callback is providing 1024 samples (mono, frequency: 44100 Hz, of type short) every 23 ms (1024.0 / 44100.0). I'm saving the samples in a buffer and use them in the encoding thread (set for mode: wide
2013 Jan 30
3
[LLVMdev] Calling dispatch_async() within call to ExecutionEngine::runFunction()
My host app calls runFunction() on my JITed code. It, in turn, calls a C function ("decode()") in the host app that then calls dispatch_async(). The runFunction() call returns as expected, but the block passed to dispatch_async() never gets called. The async block is supposed to call a function pointer callback that was passed in to decode(). Everything is being called on the main
2010 Jan 21
3
[LLVMdev] cygwin/mingw help
Can someone with cygwin/mingw access tell me what .s file gcc compiles this .c file to: static int test[100]; void *x = &test; Thanks! -Chris
2008 Nov 23
2
[LLVMdev] RFC: Mangling Unnamed Global Values
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