Hi,
>> + /* Return-address signing state is toggled by DW_CFA_GNU_window_save
>> (where
>> + REG_UNDEFINED means enabled), or set by a DW_CFA_expression. */
>
> Needs updating to REG_UNSAVED_ARCHEXT.
>
> OK with that changes, thanks, and sorry for the delays & runaround.
Thanks, I've
Wilco Dijkstra writes:
> Hi,
>
>> @Wilco, can you please send the rebased patch for patch review? We would
>> need in out openSUSE package soon.
>
> Here is an updated and rebased version:
>
> Cheers,
> Wilco
>
> v4: rebase and add REG_UNSAVED_ARCHEXT.
>
> A recent change only initializes the
Hi,
> @Wilco, can you please send the rebased patch for patch review? We would
> need in out openSUSE package soon.
Here is an updated and rebased version:
Cheers,
Wilco
v4: rebase and add REG_UNSAVED_ARCHEXT.
A recent change only initializes the regs.how[] during Dwarf unwinding
which
On 1/12/23 19:57, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Jan 10, 2023 at 04:33:59PM +, Wilco Dijkstra via Gcc-patches
> wrote:
>> Hi Szabolcs,
>>
>>> i would keep the assert: how[reg] must be either UNSAVED or UNDEFINED
>>> here, other how[reg] means the toggle cfi instruction is
On Tue, Jan 10, 2023 at 04:33:59PM +, Wilco Dijkstra via Gcc-patches wrote:
> Hi Szabolcs,
>
> > i would keep the assert: how[reg] must be either UNSAVED or UNDEFINED
> > here, other how[reg] means the toggle cfi instruction is mixed with
> > incompatible instructions for the pseudo reg.
> >
Jakub Jelinek writes:
> On Thu, Jan 12, 2023 at 03:22:56PM +, Richard Sandiford wrote:
>> If we have a new enum, I think we should handle it explicitly. The fact
>> that the information isn't propagated between frames is a key part of
>> the semantics.
>>
>> >> Another option is to just
On Thu, Jan 12, 2023 at 03:22:56PM +, Richard Sandiford wrote:
> If we have a new enum, I think we should handle it explicitly. The fact
> that the information isn't propagated between frames is a key part of
> the semantics.
>
> >> Another option is to just define the arch dependent value
Jakub Jelinek writes:
> On Thu, Jan 12, 2023 at 01:28:59PM +0100, Jakub Jelinek wrote:
>> > Although we don't AFAIK support using DW_CFA_undefined with RA signing,
>> > the failure mode would be non-obvious: it would effectively toggle the
>> > bit on.
>>
>> We don't install unwind-dw2.h nor
On Thu, Jan 12, 2023 at 01:28:59PM +0100, Jakub Jelinek wrote:
> > Although we don't AFAIK support using DW_CFA_undefined with RA signing,
> > the failure mode would be non-obvious: it would effectively toggle the
> > bit on.
>
> We don't install unwind-dw2.h nor give user code access to the how
On Thu, Jan 12, 2023 at 12:05:45PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Wed, Jan 11, 2023 at 11:59:27AM +, Wilco Dijkstra wrote:
> >> Hi,
> >>
> >> > On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
> >> >> Anyway, the sooner this makes it into gcc trunk, the
Richard Sandiford via Gcc-patches writes:
> Jakub Jelinek writes:
>> On Wed, Jan 11, 2023 at 11:59:27AM +, Wilco Dijkstra wrote:
>>> Hi,
>>>
>>> > On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
>>> >> Anyway, the sooner this makes it into gcc trunk, the better, it breaks
>>> >>
Jakub Jelinek writes:
> On Wed, Jan 11, 2023 at 11:59:27AM +, Wilco Dijkstra wrote:
>> Hi,
>>
>> > On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
>> >> Anyway, the sooner this makes it into gcc trunk, the better, it breaks
>> >> quite
>> >> a lot of stuff.
>> >
>> > Yep, please,
On Wed, Jan 11, 2023 at 11:59:27AM +, Wilco Dijkstra wrote:
> Hi,
>
> > On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
> >> Anyway, the sooner this makes it into gcc trunk, the better, it breaks
> >> quite
> >> a lot of stuff.
> >
> > Yep, please, we're also waiting for this patch
Hi,
> On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
>> Anyway, the sooner this makes it into gcc trunk, the better, it breaks quite
>> a lot of stuff.
>
> Yep, please, we're also waiting for this patch for pushing to our gcc13
> package.
Well I'm waiting for an OK from a maintainer...
On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
> Anyway, the sooner this makes it into gcc trunk, the better, it breaks quite
> a lot of stuff.
Yep, please, we're also waiting for this patch for pushing to our gcc13 package.
Cheers,
Martin
On Tue, Jan 10, 2023 at 04:33:59PM +, Wilco Dijkstra via Gcc-patches wrote:
> @@ -1204,10 +1203,15 @@ execute_cfa_program (const unsigned char *insn_ptr,
> case DW_CFA_GNU_window_save:
> #if defined (__aarch64__) && !defined (__ILP32__)
> /* This CFA is multiplexed with Sparc.
Hi Szabolcs,
> i would keep the assert: how[reg] must be either UNSAVED or UNDEFINED
> here, other how[reg] means the toggle cfi instruction is mixed with
> incompatible instructions for the pseudo reg.
>
> and i would add a comment about this e.g. saying that UNSAVED/UNDEFINED
> how[reg] is used
The 01/03/2023 17:27, Wilco Dijkstra wrote:
>
> > Also, if I understood correctly, the reason we use REG_UNSAVED is to
> > ensure that state from one frame isn't carried across to a parent frame,
> > in cases where the parent frame lacks any signing. That is, each frame
> > should start out with
Hi Richard,
> Hmm, but the point of the original patch was to support code generators
> that emit DW_CFA_val_expression instead of DW_CFA_AARCH64_negate_ra_state.
> Doesn't this patch undo that?
Well it wasn't clear from the code or comments that was supported. I've
added that back in v2.
>
The 12/06/2022 11:58, Wilco Dijkstra wrote:
> > i don't think how[*RA_STATE] can ever be set to REG_SAVED_OFFSET,
> > this pseudo reg is not spilled to the stack, it is reset to 0 in
> > each frame and then toggled within a frame.
>
> It's is just a state, we can use any state we want since it is
Hi,
> i don't think how[*RA_STATE] can ever be set to REG_SAVED_OFFSET,
> this pseudo reg is not spilled to the stack, it is reset to 0 in
> each frame and then toggled within a frame.
It's is just a state, we can use any state we want since it is a pseudo reg.
These registers are global and
The 12/05/2022 19:04, Richard Sandiford wrote:
> Wilco Dijkstra writes:
> > A recent change only initializes the regs.how[] during Dwarf unwinding
> > which resulted in an uninitialized offset used in return address signing
> > and random failures during unwinding. The fix is to use
Wilco Dijkstra writes:
> A recent change only initializes the regs.how[] during Dwarf unwinding
> which resulted in an uninitialized offset used in return address signing
> and random failures during unwinding. The fix is to use REG_SAVED_OFFSET
> as the state where the return address signing
A recent change only initializes the regs.how[] during Dwarf unwinding
which resulted in an uninitialized offset used in return address signing
and random failures during unwinding. The fix is to use REG_SAVED_OFFSET
as the state where the return address signing bit is valid, and if the
state is
24 matches
Mail list logo
