on 2024/6/17 20:57, Peter Bergner wrote:
> On 6/16/24 9:40 PM, Kewen.Lin wrote:
>> on 2024/6/17 10:31, Peter Bergner wrote:
>>> On 6/16/24 9:10 PM, Kewen.Lin wrote:
on 2024/6/15 01:05, Peter Bergner wrote:
> That said, the --with-cpu=power5 build without fortran did bootstrap and
> reg
On 6/16/24 9:40 PM, Kewen.Lin wrote:
> on 2024/6/17 10:31, Peter Bergner wrote:
>> On 6/16/24 9:10 PM, Kewen.Lin wrote:
>>> on 2024/6/15 01:05, Peter Bergner wrote:
That said, the --with-cpu=power5 build without fortran did bootstrap and
regtest with no regressions, so the build did test
On 6/16/24 9:10 PM, Kewen.Lin wrote:
> on 2024/6/15 01:05, Peter Bergner wrote:
>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>> regtest with no regressions, so the build did test that code path and
>> exposed no problems.
>
> OK, nice! Thanks!
I assume this means y
on 2024/6/15 01:05, Peter Bergner wrote:
> On 6/13/24 10:26 PM, Peter Bergner wrote:
>> On 6/13/24 9:26 PM, Kewen.Lin wrote:
> I understand this is just copied from the if arm, but if I read this
> right, it can be
> simplified as:
Ok, I'll retest with that simplification.
>>
on 2024/6/17 10:31, Peter Bergner wrote:
> On 6/16/24 9:10 PM, Kewen.Lin wrote:
>> on 2024/6/15 01:05, Peter Bergner wrote:
>>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>>> regtest with no regressions, so the build did test that code path and
>>> exposed no problems.
On 6/13/24 10:26 PM, Peter Bergner wrote:
> On 6/13/24 9:26 PM, Kewen.Lin wrote:
I understand this is just copied from the if arm, but if I read this
right, it can be
simplified as:
>>>
>>> Ok, I'll retest with that simplification.
>
> So I retested a normal powerpc64le-linux build
On 6/13/24 9:26 PM, Kewen.Lin wrote:
> on 2024/6/13 21:24, Peter Bergner wrote:
>> On 6/13/24 12:35 AM, Kewen.Lin wrote:
@@ -826,7 +826,14 @@ rs6000_stack_info (void)
info->ehrd_offset -= info->rop_hash_size;
}
else
- info->ehrd_offset = info->gp_save_offset
on 2024/6/13 21:24, Peter Bergner wrote:
> On 6/13/24 12:35 AM, Kewen.Lin wrote:
>>> @@ -826,7 +826,14 @@ rs6000_stack_info (void)
>>> info->ehrd_offset -= info->rop_hash_size;
>>> }
>>>else
>>> - info->ehrd_offset = info->gp_save_offset - ehrd_size;
>>> + {
>>> + info->eh
On 6/13/24 12:35 AM, Kewen.Lin wrote:
>> @@ -826,7 +826,14 @@ rs6000_stack_info (void)
>>info->ehrd_offset -= info->rop_hash_size;
>> }
>>else
>> -info->ehrd_offset = info->gp_save_offset - ehrd_size;
>> +{
>> + info->ehrd_offset = info->gp_save_offset - ehrd_size;
Hi Peter,
on 2024/6/8 12:06, Peter Bergner wrote:
> We currently only compute the offset for the ROP hash save location in
> the stack frame for Altivec compiles. For non-Altivec compiles when we
> emit ROP mitigation instructions, we use a default offset of zero which
> corresponds to the backch
Ping.
On 6/7/24 11:06 PM, Peter Bergner wrote:
> We currently only compute the offset for the ROP hash save location in
> the stack frame for Altivec compiles. For non-Altivec compiles when we
> emit ROP mitigation instructions, we use a default offset of zero which
> corresponds to the backchain
We currently only compute the offset for the ROP hash save location in
the stack frame for Altivec compiles. For non-Altivec compiles when we
emit ROP mitigation instructions, we use a default offset of zero which
corresponds to the backchain save location which will get clobbered on
any call. Th
12 matches
Mail list logo
