[LLVMdev] load widening conflicts with AddressSanitizer

[Criswell, John T]

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>