[LLVMdev] load widening conflicts with AddressSanitizer

[Kostya Serebryany]

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.

--kcc



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