similar to: [LLVMdev] AddressSanitizer flags in LLVM 3.5

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

________________________________ 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

Hi lists, I am encountering a large number of check-clang failures after building Clang/LLVM with -DLLVM_USE_SANITIZER=Address. I have reported the issue on Bugzilla (https://bugs.llvm.org/show_bug.cgi?id=47678). I cannot even compile helloworld.c with the resulting clang tool without a lot of false positives from ASan. Is it because I am not supposed to use GCC's AddressSanitizer when

Dear All, I think adding metadata and expecting transforms to repect it is a bad idea. It is just too easy for someone who does not know about the metadata to add a transform that ignores it. As for SAFECode, I think we have one of several options for handling load-widening. The most obvious one is to have a pass that just boosts the allocation size of any alloca with an align 16 attribute;

Fix is in (r167460). On Tue, Nov 6, 2012 at 6:18 PM, Kostya Serebryany <kcc at google.com> wrote: > The fix is under review. > > --kcc > > > On Tue, Nov 6, 2012 at 6:08 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > >> At 167457 on x86_64-apple-darwin12, I am seeing a slew of >> AddressSanitizer failures due to >> unresolved symbols

On Fri, Dec 9, 2011 at 11:16 AM, Eric Christopher <echristo at apple.com>wrote: > > On Dec 9, 2011, at 11:12 AM, Kostya Serebryany wrote: > > > Yes, we have no ASRL with -no_pie. > > Can we disable ASRL even with -pie? > > On linux we can do it with "setarch x86_64 -R". > > > > You asked about link time. Now it sounds like you're talking

On Dec 9, 2011, at 11:23 AM, Kostya Serebryany wrote: > > > On Fri, Dec 9, 2011 at 11:16 AM, Eric Christopher <echristo at apple.com> wrote: > > On Dec 9, 2011, at 11:12 AM, Kostya Serebryany wrote: > > > Yes, we have no ASRL with -no_pie. > > Can we disable ASRL even with -pie? > > On linux we can do it with "setarch x86_64 -R". > >

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

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

On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <criswell at illinois.edu>wrote: > Dear All, > > I think adding metadata and expecting transforms to repect it is a bad > idea. It is just too easy for someone who does not know about the metadata > to add a transform that ignores it. > > As for SAFECode, I think we have one of several options for handling >

The fix is under review. --kcc On Tue, Nov 6, 2012 at 6:08 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > At 167457 on x86_64-apple-darwin12, I am seeing a slew of > AddressSanitizer failures due to > unresolved symbols such as... > > Exit Code: 1 > Command Output (stderr): > -- > Undefined symbols for architecture x86_64: > "___asan_init",

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

At 167457 on x86_64-apple-darwin12, I am seeing a slew of AddressSanitizer failures due to unresolved symbols such as... Exit Code: 1 Command Output (stderr): -- Undefined symbols for architecture x86_64: "___asan_init", referenced from: _asan.module_ctor in shared-lib-test-so-moBSTe.o "___asan_register_globals", referenced from: _asan.module_ctor in

On Dec 16, 2011, at 12:39 PM, Kostya Serebryany wrote: > > Do we consider the above transformation legal? Yes, the transformation is perfectly legal for the normal compiler. > > I would argue that it should not be legal. We don't actually know what > > comes after the 22 byte object. Is it another memory object? A > > memory-mapped I/O device? Unmapped memory?

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

On Dec 17, 2011, at 7:40 AM, Rafael Ávila de Espíndola wrote: > On 16/12/11 08:46 PM, Chris Lattner wrote: >> I'm not opposed to disabling this transformation when asan is on, we just need a clean way to express this in the IR. > > Could clang be aware of asan being on and introduce a "please don't > widen" metadata on local variable accesses? Yes, "we

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

On Mon, Dec 19, 2011 at 4:27 PM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 17, 2011, at 7:40 AM, Rafael Ávila de Espíndola wrote: > > > On 16/12/11 08:46 PM, Chris Lattner wrote: > >> I'm not opposed to disabling this transformation when asan is on, we > just need a clean way to express this in the IR. > > > > Could clang be aware of