[LLVMdev] load widening conflicts with AddressSanitizer
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.
>> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev