[LLVMdev] load widening conflicts with AddressSanitizer

Reid Kleckner reid.kleckner at gmail.com
Fri Dec 16 15:22:00 PST 2011

On Fri, Dec 16, 2011 at 6:08 PM, Kostya Serebryany <kcc at google.com> wrote:

>  In this case, we have an array of 22 bytes which is 16-aligned.
>> I suspect that load widening changed the alignment of alloca instruction
>> to make the transformation legal. Right?
>> Can we change the load widening algorithm to also change the size of
>> alloca instruction to be dividable by 16?
>> This will solve the problem, at least the variant I observe now.
>> I believe it is 16-byte aligned based on ABI requirements for x86-64,
>> though you're right that the optimizer will increase alignment in other
>> cases.  In any case, we don't want to increase the size of the object,
>> because that would prevent packing some other data in after it.  For
>> example, a 2-byte aligned 10 byte object can be placed after it in memory
>> if we keep it 22-bytes in size.
> ok.
> I wonder if the load widening can attach some metadata to the stack
> objects, accesses to which it has modified?
> Then asan will increase the alloca size as appropriate (it does it anyway).
This doesn't seem like a general solution.  What if there is some heap
allocated buffer proven to be 16 byte aligned, but 22 bytes long?  Load
widening may occur, but you won't be able to fudge the size.

> Why you don't like the idea to disable or restrict the widening when asan
> is on?

I agree this seems reasonable.

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

More information about the llvm-dev mailing list