similar to: [LLVMdev] DEBUG_RUNTIME unused?

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] DEBUG_RUNTIME unused?"

2012 Dec 21
1
[LLVMdev] llvm 3.2 regression
Neither we have them now. Unfortunately disabling the test in the 3.2 branch won't fix the problem, and the actual fix may require cherry-picking a number of recent CLs, which may be rather intrusive. On Fri, Dec 21, 2012 at 12:06 PM, Alexey Samsonov <samsonov at google.com> wrote: > +glider > > Weird, we haven't seen problems with this test for quite a while. > >
2013 Nov 19
1
[LLVMdev] Broken build: r194813
Hi, can you please check the problem is fixed by r195125? On Tue, Nov 19, 2013 at 2:35 PM, Alexander Potapenko <glider at google.com> wrote: > Hi Cameron, > > I'm planning to address this issue today. > > HTH, > Alex > > On Mon, Nov 18, 2013 at 9:45 PM, Cameron McInally > <cameron.mcinally at nyu.edu> wrote: >> Hey guys, >> >> My local
2012 Dec 23
0
[LLVMdev] llvm 3.2 regression
Jack, > On Fri, Dec 21, 2012 at 05:58:59PM +0400, Alexander Potapenko wrote: >> Neither we have them now. > > Alexander, > Do you mean to say that you can't reproduce this failure locally on x86_64 darwin? > I am testing with current llvm 3.2 branches for llvm/compiler-rt/clang/polly/testsuite > against Xcode 4.5.2 on x86_64-apple-darwin12 using a cmake build
2012 Nov 30
1
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
No, we are not going to use mach_inject. This isn't portable and may be even harder to set up than mach_override. The new ASan runtime will use the dylib interposition and will in fact require DYLD_INSERT_LIBRARIES to work. However ASan already handles it correctly itself: if the corresponding env var is missing the app is just re-execed. Dylib interposition is supported by Apple and should
2012 Nov 29
0
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
If this is the same test: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/eh/cond1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1, then it doesn't fail for me on Mac OS 10.8 with ASan (Clang r168632) Have you tried symbolizing the report? On Thu, Nov 29, 2012 at 11:07 AM, Alexander Potapenko <glider at google.com> wrote: > Jack, can you please upload this test somewhere?
2013 Nov 19
0
[LLVMdev] Broken build: r194813
Hi Cameron, I'm planning to address this issue today. HTH, Alex On Mon, Nov 18, 2013 at 9:45 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > Hey guys, > > My local build is broken after: > >>r194813 | glider | 2013-11-15 08:13:01 -0500 (Fri, 15 Nov 2013) | 2 lines >> >>[ASan] Add the configure+make rules for building the ASan runtime for iOS
2012 Dec 04
0
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
On Tue, Dec 04, 2012 at 09:46:09AM -0800, Alexander Potapenko wrote: > +kledzik at apple.com > The dynamic runtime is using dylib interposition (google for > "__DATA,__interpose). > If I'm understanding correctly (Nick, can you please confirm this?) > this allows to interpose the function regardless of the two-level > namespace. > The support for dynamic runtime in
2011 Dec 09
2
[LLVMdev] [PATCH] Add the disable_aslr option that will disable the address space layout randomization under AddressSanitizer on 10.6
+llvmdev Question to MacOS gurus: is there a way to disable ASLR (address space layout randomization) on Darwin at link time instead of doing setenv("DYLD_NO_PIE", "1", 1); and reexec? Thanks, --kcc On Fri, Dec 9, 2011 at 4:28 AM, Alexander Potapenko <glider at google.com>wrote: > The attached patch introduces the disable_aslr option (off by default) > and the
2012 Dec 04
0
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
On Tue, Dec 04, 2012 at 10:36:18AM -0800, Alexander Potapenko wrote: > Currently the replacement of allocation routines is based on creating > a new malloc zone and a new CFAllocator (because the allocator > replacement is done later than it could be, we must have both). This > makes us depend on CoreFoundation to call CFAllocatorSetDefault. > Because of some bugs in CF which start
2012 Dec 04
3
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
+kledzik at apple.com The dynamic runtime is using dylib interposition (google for "__DATA,__interpose). If I'm understanding correctly (Nick, can you please confirm this?) this allows to interpose the function regardless of the two-level namespace. The support for dynamic runtime in ASan is almost there. But the new interposition method has revealed some issues with the allocator which
2011 Dec 28
0
[LLVMdev] -f[no-]omit-frame-pointer
On Wed, Dec 28, 2011 at 12:35 AM, Kostya Serebryany <kcc at google.com> wrote: > > > On Tue, Dec 27, 2011 at 12:22 PM, Joerg Sonnenberger > <joerg at britannica.bec.de> wrote: >> >> On Tue, Dec 27, 2011 at 12:10:54PM -0800, Kostya Serebryany wrote: >> > What would be the best fix for asan? >> >> Can you be explicit what you need to asan?
2012 Nov 30
2
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Is the native function interposition that is being adopted based on...
2012 Dec 04
3
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
Currently the replacement of allocation routines is based on creating a new malloc zone and a new CFAllocator (because the allocator replacement is done later than it could be, we must have both). This makes us depend on CoreFoundation to call CFAllocatorSetDefault. Because of some bugs in CF which start firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of
2011 Dec 09
0
[LLVMdev] [PATCH] Add the disable_aslr option that will disable the address space layout randomization under AddressSanitizer on 10.6
Options when creating a main executable -pie This makes a special kind of main executable that is position independent (PIE). On Mac OS X 10.5 and later, the OS the OS will load a PIE at a random address each time it is executed. You cannot create a PIE from .o files compiled with -mdy- namic-no-pic. That means the
2011 Dec 28
1
[LLVMdev] [PATCH] AddressSanitizer: force the __asan_unregister_globals to reside in the runtime library
Hi, This patch adds __asan_unregister_globals() to the list of symbols forced into the RTL -- Alexander Potapenko Software Engineer Google Moscow -------------- next part -------------- A non-text attachment was scrubbed... Name: asan-force-unregister.patch Type: text/x-patch Size: 427 bytes Desc: not available URL:
2011 Dec 29
1
[LLVMdev] [PATCH] AddressSanitizer: emit the unwind tables for the runtime library.
(see http://code.google.com/p/address-sanitizer/issues/detail?id=23) In order for exceptions to work correctly, it should be possible to unwind through the functions wrapped by ASan RTL (in particular, __cxa_throw()) Because we intentionally build the runtime with -fno-exceptions, we need at least the unwind tables to support _Unwind_Backtrace(). -- Alexander Potapenko Software Engineer Google
2013 Apr 09
0
[LLVMdev] [cfe-dev] Google Summer of Code 2013
Will someone in charge please complete LLVM's page at google-melange.com? Without that LLVM is missing in the list of participants: http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2013 On Mon, Apr 8, 2013 at 11:11 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Dear All > > I'd like to announce that this year LLVM Compiler Infrastructure >
2011 Dec 06
0
[LLVMdev] Assertion `PI && "Expected required passes to be initialized"' failed for AliasAnalysis.
Hi Alexander, I had the same error: sincos: /home/marcusmae/rpmbuild/BUILD/llvm/lib/VMCore/PassManager.cpp:635: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*): Assertion `PI && "Expected required passes to be initialized"' failed. The solution was to add: PassRegistry &Registry = *PassRegistry::getPassRegistry(); initializeCore(Registry);
2012 Nov 30
3
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
Looks like this happens on x86_64 because the position of __cxa_throw is too far from the allocated branch island (should be <2G). This can be solved by allocating the branch islands somewhere near the text segment (look for kIslandEnd in asan_mac.cc, this is currently 0x7fffffdf0000) or by patching the function with a longer instruction sequence that stores the jump target in a register and
2012 Nov 30
0
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
Just want to remind everyone that we plan to stop using mach_override in asanin favor of OSX's native function interposition. So, we probably don't want to spend too much effort fixing mach_override. --kcc On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote: > Looks like this happens on x86_64 because the position of __cxa_throw > is too far from