Re: [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting

On Mon, Jan 16, 2017 at 03:11:56PM +0000, Yao Qi wrote:
> On 17-01-16 13:32:31, Dave Martin wrote:
> > On Mon, Jan 16, 2017 at 12:20:38PM +0000, Yao Qi wrote:
> > > On 17-01-12 11:26:07, Dave Martin wrote:
> > > > This patch adds support for manipulating a task's vector length at
> > > > runtime via ptrace.
> > > > 
> > > 
> > > I hope kernel doesn't provide such interface to ptracer to change vector
> > > length.
> > 
> > It does, with this patch, beacuse...
> > 
> > > The vector length is sort of a read-only property of thread/process/
> > > program to debugger, unless we really have a clear requirement to modify
> > > vector length in debugging.  I may miss something because I haven't debug
> > > SVE code yet.
> > 
> > ...the vector length is no longer read-only for the task, thanks to
> > the new prctls().
> 
> What I meant "read-only" is that debugger can't change it, while the program
> itself can change it via prctl().

I see.

> > 
> > This does add complexity, but I figured that any programmer's model
> > state that the thread can modify for itself should be modifiable by the
> > debugger, if for no other reason than the user may want to experiment to
> > see what happens.  Without a ptrace interface, it would be necessary
> > to inject a prctl() call into the target, which is possible but awkward.
> 
> We only need such interface if it is useful, see more below.
> 
> Suppose it is useful to change vector length through ptrace, we should align
> ptrace interface to prctl() as much as possible.  Looks that both prctl
> change and ptrace change can go through sve_set_vector_length, easy to keep
> two consistent.
> 
> > 
> > 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.
> 
> > 
> > Access via ptrace also allows things like trapping on exec, fork or
> > clone and changing the vector length for the new process or thread
> > before it starts to run.  I'm guessing here, but such a scenario seems
> > legitimate (?)
> > 
> 
> Yes, these cases are valid, but the usefulness is still questionable to
> me.  I just doubt that SVE developers do need to change vector length
> when they are debugging code.  Note that it is not my strong objection
> to this patch, if kernel people believe this is useful, I am fine with
> it.

That's fair.  I'll leave the patch there for now and see if anyone else
has a comment to make, but it could be removed without affecting
anything else.

Are there situations in which injecting a function call into the target
won't work, i.e., where we couldn't do:

set prctl(...)

?

Using the prctl interface this way, it would also be preferable to refer
to the #defines by name.

Cheers
---Dave