[RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting
Dave.Martin at arm.com
Mon Jan 16 08:31:23 PST 2017
On Mon, Jan 16, 2017 at 03:47:55PM +0000, Pedro Alves wrote:
> On 01/16/2017 03:11 PM, Yao Qi wrote:
> >> >
> >> > gdb must already re-detect the vector length on stop, since the target
> >> > could have called the prctl() in the meantime.
> > Yes, gdb assumes the vector length may be changed, so it re-detects on
> > every stop, but I don't see the need for gdb to change the vector length.
> Do we need to consider inferior function calls here?
> Say the program is stopped in code that assumes "vector length N", and
> the user does "print some_function_that_assumes_some_other_vector_length ()".
> Is that a use case we need to cover?
> If so, to make it work correctly, the debugger needs to be able to change the
> vector length to the length assumed by that called function, and then
> restore it back after the call completes (or is aborted).
> I have no idea whether the debugger will be able to figure
> out a function's assumed vector length from debug info or some such.
I think the proposed ptrace interface can support this -- i.e., it
should provide everything needed to save off the VL and register state,
switch VL, do something else, then restore the VL and state (if not,
that's a bug).
My current position is that determining what vector length is
required by what function or binary is a 100% userspace problem, though.
ELF/DWARF could have annotations about this, though it wouldn't
necessarily be per-function -- you might require a whole image to be
built for the same vector length (if any).
More information about the linux-arm-kernel