[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6357c8a-43a3-ecca-83e3-670e18303bcb@linux.com>
Date: Wed, 28 Feb 2018 13:27:32 +0300
From: Alexander Popov <alex.popov@...ux.com>
To: Laura Abbott <labbott@...hat.com>, Kees Cook <keescook@...omium.org>,
kernel-hardening@...ts.openwall.com, Will Deacon <will.deacon@....com>,
richard.sandiford@....com
Subject: Re: [PATCH 2/2] gcc-plugins: stackleak: Update for gcc-8
On 27.02.2018 13:30, Richard Sandiford wrote:
> Laura Abbott <labbott@...hat.com> writes:
>> On 02/24/2018 06:04 AM, Alexander Popov wrote:
>>> Hello Laura,
>>>
>>> Thanks for the cooperation!
>>>
>>> On 23.02.2018 02:14, Laura Abbott wrote:
>>>> +#if BUILDING_GCC_VERSION >= 8000
>>>> +bool check_frame_size()
>>>> +{
>>>> + return maybe_ge(get_frame_size(), track_frame_size);
>>>
>>> After looking through this guide
>>> https://gcc.gnu.org/onlinedocs//gccint/Guidelines-for-using-poly_005fint.html#Guidelines-for-using-poly_005fint
>>> it seems to me that we should better use something like that:
>>>
>>> poly_int64 frame_size = get_frame_size();
>>>
>>> if (frame_size.to_constant() >= track_frame_size)
>>> return 0;
>>>
>>> May I ask for your opinion?
>>>
>>
>> I was a bit wary of using to_constant() because I wasn't 100% sure
>> I could make the assertion that it could actually be a constant so using
>
> Yeah, the assert would fire for SVE functions that spill SVE registers
> to the stack.
>
>> maybe_ge seemed like the conservative approach. This also getting into
>> compiler internals so it's possible I'm misunderstanding how poly_ints
>> are supposed to work.
>
> The maybe_ge patch looks good to me FWIW.
Thanks, Laura and Richard!
I see the rationale, I will use maybe_ge() in the next version of the patch.
Best regards,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
