> -----Original Message----- > From: Richard Sandiford <richard.sandif...@arm.com> > Sent: Tuesday, July 15, 2025 9:41 AM > To: Tamar Christina <tamar.christ...@arm.com> > Cc: Yury Khrustalev <yury.khrusta...@arm.com>; gcc-patches@gcc.gnu.org; Mark > Rutland <mark.rutl...@arm.com> > Subject: Re: [PATCH 1/1] aarch64: Adapt unwinder to linux's SME signal > behaviour > > Tamar Christina <tamar.christ...@arm.com> writes: > > One question I did have not directly related to the unwinder changes, > > But the ABI mentions that if any of the reserved bytes in TPIDR2_EL0 > > Block are non-zero that TPIDR2_EL0 must be left unchanged [1]. > > The full requirement is: > > If TPIDR2_EL0 is nonnull and if any reserved byte in the first 16 bytes > of the TPIDR2 block has a nonzero value, the thread must do one of the > following: > > * leave TPIDR2_EL0 unchanged; > * abort in some platform-defined manner; or > * handle the nonzero reserved bytes of the TPIDR2 block in accordance > with future versions of the AAPCS64. > > So... > > > If that's the case what does it mean for the lazy save scheme, since it > > requires that TPIDR2_EL0 be 0 at the end of the save? I see we don't > > actually check that in e.g. __arm_za_disable, we just unconditionally > > zero TPIDR2_EL0. > > ...we take the second or third option (aborting or handling in line > with a future PCS version). Currently it's always the aborting option, > since there has been no addition to TPIDR2 blocks since their original > definition. > > __arm_za_disable is documented as saving in the same way as __arm_tpidr2_save, > and __arm_tpidr2_save is documented as doing: > > * If any of the reserved bytes in the first 16 bytes of the TPIDR2 > block are nonzero, the subroutine either: > * aborts in some platform-defined manner; or > * handles the nonzero reserved bytes of the TPIDR2 block in > accordance with future versions of the AAPCS64. >
Ah I see, it's handled in the call to __libgcc_arm_tpidr2_save, Thanks, All clear now! Tamar > Richard
