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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
