Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] Google Summer of Code 2013"
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
>
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
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
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 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
2013 Nov 18
2
[LLVMdev] Broken build: r194813
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
> simulator.
Tim Northover was kind enough to track this down to a dependency on
the “iphonesimulator” SDK. How should this issue be resolved? I'm
currently following the receipe to build
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 Nov 29
5
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
Jack, can you please upload this test somewhere?
On Thu, Nov 29, 2012 at 10:09 AM, Kostya Serebryany <kcc at google.com> wrote:
> +glider
> The compiler hardly matters here, I would expect the same failures with
> clang.
> Alex, could you please take a look?
>
> --kcc
>
>
> On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu>
>
2015 Feb 20
1
Help wanted! - Icecast is applying for Google Summer of Code through Xiph.org
Hi everyone,
We've decided to apply for this year's Google Summer of Code. Xiph.org
has taken part before, so we hope to get at least one or two, maybe even
3 students.
If we get chosen we need project ideas and mentors though. We've already
started to collect some ideas that would hopefully be sized for students
here:
https://wiki.xiph.org/Summer_of_Code_2015
That page also lists
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 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?
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
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...
2014 Sep 05
4
[LLVMdev] [cfe-dev] Address sanitizer regression test failures for PPC64 targets
Note that I've set the SA_NODEFER flag for the SEGV handler in the
ASan runtime only a couple of days ago.
Not sure that could've affected this test though; without that flag
the second SEGV would've simply crashed the program. But you can try
removing the flag from
compiler-rt/trunk/lib/sanitizer_common/sanitizer_posix_libcdep.cc and
see if that makes any difference.
HTH,
Alex
On
2011 Dec 06
2
[LLVMdev] Assertion `PI && "Expected required passes to be initialized"' failed for AliasAnalysis.
Dear lazydev,
I'm writing an instrumentation pass that depends on AliasAnalysis. My
getAnalysisUsage() looks as follows:
2453 void ThreadSanitizer::getAnalysisUsage(AnalysisUsage &AU) const {
2454 AU.addRequired<TargetData>();
2455 AU.addRequired<AliasAnalysis>();
2456 }
and the pass initialization:
2668 char ThreadSanitizer::ID = 0;
2669
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
2010 Apr 10
1
[LLVMdev] *Important*: Google Summer of Code 2010
Dear prospective GSoC Students!
Please note, that you won't receive any reviews of your proposals from
SoC webapp automatically. You **need to explicitly** subscribe for
them. Please do it now and respond to requests / comments already made
in some of applications.
Thanks!
--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
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