[LLVMdev] load widening conflicts with AddressSanitizer

Kostya Serebryany kcc at google.com
Fri Dec 16 15:28:53 PST 2011

On Fri, Dec 16, 2011 at 3:22 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote:

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

A 16-byte aligned heap buffer of 22 bytes is a very unlikely thing (still
possible, so I agree with you)

>> Why you don't like the idea to disable or restrict the widening when asan
>> is on?
> I agree this seems reasonable.

Btw, having a flag that would restrict widening will be helpful for tools
like Valgrind/Memcheck and Dr.Memory.

Currently, in order to run Valgrind we have to build programs with "gcc -O1
-disable-some-more-stuff" because of a similar issue.
Valgrind does not catch stack buffer overflows so it only applies to heap.


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

More information about the llvm-dev mailing list