On 8 Oct 2021, at 18:04, Mark Brown [off-list ref] wrote:

On Fri, Oct 08, 2021 at 04:45:44PM +0000, Alan Hayward wrote:

quoted

quoted

On 8 Oct 2021, at 16:28, Mark Brown [off-list ref] wrote:
On Fri, Oct 08, 2021 at 02:11:46PM +0000, Alan Hayward wrote:

quoted

quoted

quoted

Can NT_ARM_SSVE return a fpsimd?

quoted

quoted

It's documented that way for simplicity but in the current
implementation it won't ever actually do so in practice.  The
only case where I could see that it might happen would be if we
change the syscalls to stay in streaming mode over syscall, in
that case we could do as we do for SVE and preserve FPSIMD
registers only.  At present we drop out of streaming mode if we
get a syscall with it enabled so it's a non-issue, if people
agree that that's the right thing for the syscalls then we should
update the documentation to specify this since otherwise we'll
doubtless catch someone by surprise if we ever manage to start
doing it in the future.

quoted

….or it’ll end up executing some code that was written to cope with fpsimd, but has never been
run. Might be worth making it explicit in the documentation.

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?

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.

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.

You could solve that by adding an SVE_STATE_INACTIVE to the header flags. But, either way, the
debugger would then need to support the existing method and the new method (because the debugger
has no control on what OS version it’s running on).

I’d recommend leaving as is.


Alan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel