similar to: [LLVMdev] LLVMdev Digest, Vol 89, Issue 60

On Thu, Nov 24, 2011 at 7:27 AM, Daniel Dunbar <daniel at zuster.org> wrote: > Quick answers, I'm on txgiving break this week and not doing any real > work, but I will be doing more compiler-rt work when I get back > (initially focused at getting profile libs to come from compiler-rt on > Linux et al). > > On Wed, Nov 16, 2011 at 9:24 PM, Kostya Serebryany <kcc at

Hi Daniel, Chris suggested to talk to you about committing the AddressSanitizer (asan) run-time into the llvm tree (llvm-project/compiler-rt). Questions: - What is the preferred name for the directory? (asan? libasan? address_sanitizer? AdressSanitizer?) - Should the asan run-time use cmake, or just make, or what? The build is a bit tricky, especially for tests. We currently use make. - How

Quick answers, I'm on txgiving break this week and not doing any real work, but I will be doing more compiler-rt work when I get back (initially focused at getting profile libs to come from compiler-rt on Linux et al). On Wed, Nov 16, 2011 at 9:24 PM, Kostya Serebryany <kcc at google.com> wrote: > Hi Daniel, > Chris suggested to talk to you about committing the AddressSanitizer

On Mon, Nov 28, 2011 at 1:15 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Nov 24, 2011 at 7:27 AM, Daniel Dunbar <daniel at zuster.org> wrote: >> >> Quick answers, I'm on txgiving break this week and not doing any real >> work, but I will be doing more compiler-rt work when I get back >> (initially focused at getting profile libs

Hi Kostya, > [resurrecting an old mail thread about AddressSanitizer false positive caused by > load widening] > > Once the Attribute::AddressSafety is set by clang (a separate patch), fixing > this bug may look as simple as this: I don't get the point of an attribute. There's plenty of code out there that does wide loads like this directly (without them being created by

On Tue, Jan 24, 2012 at 1:23 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Kostya, > > > [resurrecting an old mail thread about AddressSanitizer false positive > caused by > > load widening] > > > > Once the Attribute::AddressSafety is set by clang (a separate patch), > fixing > > this bug may look as simple as this: > > Hi Duncan, >

Any updates on this? In particular, I'd like to see concrete patches proposed for review and inclusion into LLVM. I think having actual patches on the table and under review will help a great deal. Kostya, let me know if I can help prepare them. A few general comments as well inline... On Tue, Jul 26, 2011 at 1:57 AM, Kostya Serebryany <kcc at google.com> wrote: > On Tue, Jul 26,

Hi Kostya, > On Tue, Jan 24, 2012 at 1:23 AM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Kostya, > > > [resurrecting an old mail thread about AddressSanitizer false positive > caused by > > load widening] > > > > Once the Attribute::AddressSafety is set by clang (a separate

On Mon, Aug 1, 2011 at 12:01 PM, Chandler Carruth <chandlerc at google.com>wrote: > Any updates on this? > > In particular, I'd like to see concrete patches proposed for review and > inclusion into LLVM. I think having actual patches on the table and under > review will help a great deal. Kostya, let me know if I can help prepare > them. > Ok, I'll send the

On Jun 21, 2011, at 8:05 AM, Kostya Serebryany wrote: > Hi, > What would be our next steps in getting ASan into the LLVM trunk? > I'd like to do it in two steps, first for the LLVM part with minimal tests and then for the run-time library and all tests. > The current ASan's source repository will probably stay the primary home for the run-time library and tests as we plan

Hello, We've just released the first version of our LLVM-based address sanity checker: AddressSanitizer (http://code.google.com/p/address-sanitizer/). The tool finds out-of-bound and use-after-free bugs (the subset of bugs detectable by Valgrind/Memcheck); it consists of a LLVM compiler plugin which performs simple code instrumentation and a malloc replacement library. The main advantage of

On Thu, Jun 16, 2011 at 11:00 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 16, 2011, at 1:27 AM, Kostya Serebryany wrote: > > Hello again, > > The tool we announced 1.5 months ago has matured quite a bit. > In addition to heap out-of-bound and use-after-free bugs it also finds > stack overruns/underruns. > AddressSanitizer is being actively used by

On Tue, Jul 26, 2011 at 10:20 AM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 21, 2011, at 8:05 AM, Kostya Serebryany wrote: > > > Hi, > > What would be our next steps in getting ASan into the LLVM trunk? > > I'd like to do it in two steps, first for the LLVM part with minimal > tests and then for the run-time library and all tests. > >

________________________________ From: Kostya Serebryany [kcc at google.com] Sent: Wednesday, December 28, 2011 2:46 PM To: Criswell, John T Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] load widening conflicts with AddressSanitizer On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <criswell at illinois.edu<mailto:criswell at illinois.edu>> wrote: Dear All, I think adding

On Jun 16, 2011, at 1:27 AM, Kostya Serebryany wrote: > Hello again, > > The tool we announced 1.5 months ago has matured quite a bit. > In addition to heap out-of-bound and use-after-free bugs it also finds stack overruns/underruns. > AddressSanitizer is being actively used by the Chromium developers and already found over 20 bugs:

Hi, # TL;DR I've been building an application with and without the address sanitizer (with gcc 5.3 and clang 3.7.1) and I've observed that the application's behaviour changes (assertion hit/ not hit). I'm wondering if this could be a bug in address sanitizer or if the application I'm running is just buggy (e.g. doing bad things like relying on memory layout, etc.). I'm

This is a proposal to create memory safety instrumentation and optimization passes for LLVM. Abstract: The goal of this project is to modify SAFECode and AddressSanitizer (ASAN) to use a common set of memory safety instrumentation and optimization passes to increase code reuse. These tools and other similar ones use varying methods to detect whether memory accesses are safe, but are fundamentally

Hello again, The tool we announced 1.5 months ago has matured quite a bit. In addition to heap out-of-bound and use-after-free bugs it also finds stack overruns/underruns. AddressSanitizer is being actively used by the Chromium developers and already found over 20 bugs: http://blog.chromium.org/2011/06/testing-chromium-addresssanitizer-fast.html Question to the LLVM developers: would you

Hi, [resurrecting an old mail thread about AddressSanitizer false positive caused by load widening] Once the Attribute::AddressSafety is set by clang (a separate patch), fixing this bug may look as simple as this: --- lib/Analysis/MemoryDependenceAnalysis.cpp (revision 148708) +++ lib/Analysis/MemoryDependenceAnalysis.cpp (working copy) @@ -323,6 +323,14 @@

I'd like some similar work to be done, although I view it a bit differently. This might be a separate analysis pass that knows nothing about ASAN or SAFECode and appends metadata nodes to memory access instructions saying things like - this access can not go out of buffer bounds - this access can not touch free-ed memory - this access can not participate in a race - this read