llvm dev - Dec 2011 - [LLVMdev] load widening conflicts with AddressSanitizer

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 just need a clean way to express this in the IR."

LLVM can't have a global "bool ASANIsOn;" that the optimizers
listen to.

-Chris

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 asan being on and introduce a "please
don't
> > widen" metadata on local variable accesses?
>
> Yes, "we just need a clean way to express this in the IR."
>
> LLVM can't have a global "bool ASANIsOn;" that the optimizers
listen to.
>

A global is bad.
What about a metadata attached to a Function saying that transformations
which will read out of bounds (even "safely") are illegal?
asan and SAFEcode will add this metadata, optimizers will listen to it.

Any other suggestion?


--kcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111227/a9e51b02/attachment.html>

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; this pass would only
be scheduled to execute when the other SAFECode instrumentation passes are
scheduled to execute.  Another option would be to just disable the load-widening
transform or to use a specialized version that only widens when the allocation
size does not cause a problem.

-- John T.

________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf
of Kostya Serebryany [kcc at google.com]
Sent: Tuesday, December 27, 2011 12:57 PM
To: Chris Lattner
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] load widening conflicts with AddressSanitizer



On Mon, Dec 19, 2011 at 4:27 PM, Chris Lattner <clattner at
apple.com<mailto: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 asan being on and introduce a "please
don't
> widen" metadata on local variable accesses?
Yes, "we just need a clean way to express this in the IR."

LLVM can't have a global "bool ASANIsOn;" that the optimizers
listen to.


A global is bad.
What about a metadata attached to a Function saying that transformations which
will read out of bounds (even "safely") are illegal?
asan and SAFEcode will add this metadata, optimizers will listen to it.

Any other suggestion?


--kcc

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111228/f11f0dd4/attachment.html>