On Mon, Oct 11, 2021 at 11:15:09AM +0000, Alan Hayward wrote: > > On 8 Oct 2021, at 18:04, Mark Brown <broonie@xxxxxxxxxx> wrote: > > I will if/when it gets fixed that way. Actually, while looking > > at that code I was tempted to remove the support for returning > > FPSIMD only registers via NT_ARM_SVE entirely and just always > > convert to SVE format - I'm not sure what the use case was there? > > It's not a pressing thing but it seemed like it was a bit of an > > implementation detail that we were revealing. > What about in the write registers case? Both register sets accept FPSIMD registers for writes - we can't remove that for the SVE register set given that it's ABI. > With the existing code: > Read SVE registers with ptrace. Get FPSIMD. Update FPSIMD with new values. Write back to ptrace. > In that scenario, the internal SVE states stays “inactive” in the kernel. Right. > If ptrace always returned an SVE structure, then writing back with the same structure would cause the > SVE state to become active. It’s a small difference, but we really don’t want the debugger to effect things. With the existing code - with the wider availability of SVE hardware we'll see soon we might be looking at changing how the kernel handles enabling and disabling SVE which might mean we want to change how that looks internally anyway. Part of what has me thinking about this is that what we've got at the minute is quite tied to the implementation and we might want to change that.
Attachment:
signature.asc
Description: PGP signature
