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