On 11/29/18 5:46 PM, Jakub Jelinek wrote:
> On Thu, Nov 29, 2018 at 05:37:11PM +0100, Martin Liška wrote:
>>   0x10007fff7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x10007fff7b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x10007fff7b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x10007fff7b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x10007fff7b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> =>0x10007fff7b50: 00 00 00 00 f1 f1 f1 f1[01]f2 00 00 01 f2 f2 f2
>>   0x10007fff7b60: f2 f2 00 00 00 06 f2 f2 f2 f2 00 00 00 00 00 f3
>>   0x10007fff7b70: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x10007fff7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x10007fff7b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x10007fff7ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>
>> as seen 06f2f2f2 is completely unaligned write.
> 
> Sure, but the whole frame section where the vars from one function are
> is properly aligned.  So, you shouldn't store 0xf2f2f206, but 0xf2f20600
> one byte earlier, and then 0x0000f2f2 after it.  Of course, if we decide
> that we want to do solely SImode stores.  If we want to complicate it
> through determining costs and comparing if we should do a 1 or 2 or 4 byte
> store and if unaligned is possible and not very expensive consider even
> those in some cases, the code might be more complex.
> I guess for now I'd be fine with SImode stores only and if we get complains,
> we can address that incrementally (the question is if we'd want hooks or
> what to determine it).
> 
> 	Jakub
> 

Ok, I'm sending updated version of the patch. I factored out the shadow memory
byte emission into a class, it's responsible for underlying flushing and guarantees
that stores are 4B aligned (when beginning of stack vars is properly aligned
to ASAN_RED_ZONE_SIZE).

So far I tested the patch on x86_64-linux-gnu and ppc64le-linux-gnu machine.

Martin