On Fri, Nov 30, 2018 at 12:44:04PM +0100, Martin Liška wrote:
> 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 prope
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 0
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 0
On 11/29/18 4:17 PM, Jakub Jelinek wrote:
> On Thu, Nov 29, 2018 at 04:03:42PM +0100, Martin Liška wrote:
>>> Two problems, it uses unconditionally unaligned stores, without
>>> checking if the target supports them at all (in this case it does).
>>> And, it doesn't check if it wouldn't be more effi
On Thu, Nov 29, 2018 at 04:03:42PM +0100, Martin Liška wrote:
> > Two problems, it uses unconditionally unaligned stores, without
> > checking if the target supports them at all (in this case it does).
> > And, it doesn't check if it wouldn't be more efficient to use
> > 32-bit stores.
>
> Ok, so
On 11/28/18 12:41 PM, Jakub Jelinek wrote:
> On Wed, Sep 26, 2018 at 11:33:25AM +0200, Martin Liška wrote:
>> 2018-09-26 Martin Liska
>>
>> PR sanitizer/81715
>> * asan.c (asan_shadow_cst): Remove.
>> (asan_emit_redzone_payload): New.
>> (asan_emit_stack_protection): Make it
On Wed, Sep 26, 2018 at 11:33:25AM +0200, Martin Liška wrote:
> 2018-09-26 Martin Liska
>
> PR sanitizer/81715
> * asan.c (asan_shadow_cst): Remove.
> (asan_emit_redzone_payload): New.
> (asan_emit_stack_protection): Make it more
> flexible to support arbitrary siz
PING^3
On 10/23/18 11:02 AM, Martin Liška wrote:
> PING^2
>
> On 10/9/18 10:29 AM, Martin Liška wrote:
>> PING^1
>>
>> On 9/26/18 11:33 AM, Martin Liška wrote:
>>> On 9/25/18 5:53 PM, Jakub Jelinek wrote:
On Tue, Sep 25, 2018 at 05:26:44PM +0200, Martin Liška wrote:
> The only missing pi
PING^2
On 10/9/18 10:29 AM, Martin Liška wrote:
> PING^1
>
> On 9/26/18 11:33 AM, Martin Liška wrote:
>> On 9/25/18 5:53 PM, Jakub Jelinek wrote:
>>> On Tue, Sep 25, 2018 at 05:26:44PM +0200, Martin Liška wrote:
The only missing piece is how to implement asan_emit_redzone_payload more
PING^1
On 9/26/18 11:33 AM, Martin Liška wrote:
> On 9/25/18 5:53 PM, Jakub Jelinek wrote:
>> On Tue, Sep 25, 2018 at 05:26:44PM +0200, Martin Liška wrote:
>>> The only missing piece is how to implement asan_emit_redzone_payload more
>>> smart.
>>> It means doing memory stores with 8,4,2,1 sizes
On 9/25/18 5:53 PM, Jakub Jelinek wrote:
> On Tue, Sep 25, 2018 at 05:26:44PM +0200, Martin Liška wrote:
>> The only missing piece is how to implement asan_emit_redzone_payload more
>> smart.
>> It means doing memory stores with 8,4,2,1 sizes in order to reduce # of
>> insns.
>> Do we have somewh
On Tue, Sep 25, 2018 at 05:26:44PM +0200, Martin Liška wrote:
> The only missing piece is how to implement asan_emit_redzone_payload more
> smart.
> It means doing memory stores with 8,4,2,1 sizes in order to reduce # of insns.
> Do we have somewhere a similar code?
Yeah, that is a very important
On 9/25/18 12:40 PM, Jakub Jelinek wrote:
> On Tue, Sep 25, 2018 at 12:10:42PM +0200, Martin Liška wrote: On 9/25/18
>> 11:24 AM, Jakub Jelinek wrote:
>>> On Tue, Sep 25, 2018 at 11:05:30AM +0200, Martin Liška wrote:
As requested in PR81715, GCC emits bigger middle redzones for small
var
On Tue, Sep 25, 2018 at 12:10:42PM +0200, Martin Liška wrote: On 9/25/18
> 11:24 AM, Jakub Jelinek wrote:
> > On Tue, Sep 25, 2018 at 11:05:30AM +0200, Martin Liška wrote:
> >> As requested in PR81715, GCC emits bigger middle redzones for small
> >> variables.
> >> It's analyzed in following comme
On 9/25/18 12:10 PM, Martin Liška wrote:
> On 9/25/18 11:24 AM, Jakub Jelinek wrote:
>> On Tue, Sep 25, 2018 at 11:05:30AM +0200, Martin Liška wrote:
>>> As requested in PR81715, GCC emits bigger middle redzones for small
>>> variables.
>>> It's analyzed in following comment:
>>> https://gcc.gnu.
On 9/25/18 11:24 AM, Jakub Jelinek wrote:
> On Tue, Sep 25, 2018 at 11:05:30AM +0200, Martin Liška wrote:
>> As requested in PR81715, GCC emits bigger middle redzones for small
>> variables.
>> It's analyzed in following comment:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c28
>
> Firs
On Tue, Sep 25, 2018 at 11:05:30AM +0200, Martin Liška wrote:
> As requested in PR81715, GCC emits bigger middle redzones for small variables.
> It's analyzed in following comment:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c28
First of all, does LLVM make the variable sized red zone si
Hi.
As requested in PR81715, GCC emits bigger middle redzones for small variables.
It's analyzed in following comment:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c28
For now I'm suggesting to shrink shadow memory for variables <= 16B to 32B
(including variable storage).
LLVM is more agg
18 matches
Mail list logo
