similar to: [LLVMdev] LLVM-based address sanity checker

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

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:

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 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

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. > >

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,

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 16 June 2011 09:27, Kostya Serebryany <kcc at google.com> wrote: > Question to the LLVM developers: would you consider adding > the AddressSanitizer code to the LLVM trunk? Do you have an idea how hard would it be to port to non-x86 platforms? I saw some Intel ASM in the C++ file... The run-time library being 1.5k loc is not encouraging, but it didn't look particularly

On Thu, Jun 16, 2011 at 11:10 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 16 June 2011 09:27, Kostya Serebryany <kcc at google.com> wrote: > > Question to the LLVM developers: would you consider adding > > the AddressSanitizer code to the LLVM trunk? > > Do you have an idea how hard would it be to port to non-x86 platforms? > I saw some Intel ASM

Hi everyone, I am having troubles but this shouldn't be hard to solve for many people here. I am beginning a runtime feature for the BoundsChecking pass and I want to replace the libc malloc&free. I followed the design of AddressSanitizer (Asan) and tried to use the INTERCEPTOR macro from the interception.h file of compiler-rt library. Here is the problem. The file I modify

Hello, As far as I know, there is no MPX pass in LLVM (though the x86-64 backend already declares MPX registers and instructions). I wonder if anyone is currently working on the LLVM pass for MPX instrumentation, similar to Pointer Checker in gcc. If yes, could anyone elaborate on the status and accessability to other researchers? And if any help is needed? Prof. Santosh Nagarakatte, the author

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

Daniel, Kostya, We had a meeting with the Clang people (Chris, Doug, Ted) on Thursday before the llvmdev meeting about adding dynamic checking tools into Clang -- IOC for undefined integer behaviors, and SAFECode for memory safety. SAFECode has similar goals to AddressSanitizer, though at least for now it has more checks, but is slower. The main conclusion was that we should have a common

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

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 to use it in non-LLVM environments. Thanks, --kcc On Fri, Jun 17, 2011 at

________________________________ 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

Thanks for the fast response John. On Thu, Oct 1, 2015, at 04:51 PM, John Criswell wrote: > Dear Ed, > > First, someone has updated the DSA code in the poolalloc project to LLVM > 3.7, and a Master's student worked for me over the summer to update a > large chunk of SAFECode to LLVM 3.7. However, the update to LLVM 3.7 > isn't finished (we need to finish integrating

On Fri, Jun 17, 2011 at 12:42 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 17 June 2011 09:14, Kostya Serebryany <kcc at google.com> wrote: > >> Maybe the fallback code should just use a function call. Much simpler for >> documentation purposes. > > > Sounds good. > I implemented the asm-free way to report warnings as an option to the llvm

On 31 Jul 2017, at 19:26, Hans Wennborg <hans at chromium.org> wrote: > > On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <dimitry at andric.com> wrote: >> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org> wrote: >>> >>> 5.0.0-rc1 has just been tagged. >>> >>> Please build, test and upload binaries

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, >