Message ID | 1484220369-23970-9-git-send-email-Dave.Martin@arm.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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. 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. > As a simplification, we turn the task back into an FPSIMD-only task > when changing the vector length. If the register data is written > too, we then turn the task back into an SVE task, with changed > task_struct layout for the SVE data, before the actual data writing > is done. > > Because the vector length is now variable, sve_get() now needs to > return the real maximum for user_sve_header.max_vl, since .vl may > be less than this (that's the whole point). >
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(). 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. gdb must already re-detect the vector length on stop, since the target could have called the prctl() in the meantime. 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 (?) [...] Cheers ---Dave
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(). > > 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.
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. Thanks, Pedro Alves
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). Cheers ---Dave
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
> On 17 Jan 2017, at 10:03, Dave Martin <Dave.Martin@arm.com> wrote: > > 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. > I would say that whilst it is a very dangerous thing to do and has many consequences, there is a requirement for a gdb user to be able to change VL whilst debugging a running process, and I don’t think we should see changing VL as much different from changing a register value on the fly. Say you have a loop in assembly you are trying to debug - you might write to $x2 and then single step to see how this effects the result. With SVE code you might want to see how different VL values will effect the layout of results in the vectors, how it effects the predicates and how it changes the number of iterations the loop makes. Of course, once you exit the loop all bets are off - just like if you had been changing register values. The current proposal for gdb is that we will show $VL in the list of registers, therefore for consistency it’d make sense for the gdb user to be able to set it as if it was just another register. For this we need a simple way to change the VL in another process, and I think ptrace() is the easiest way (given that prctl() only changes its own process). > 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 Thanks, Alan.
On Tue, Jan 17, 2017 at 01:31:03PM +0000, Alan Hayward wrote: > > > On 17 Jan 2017, at 10:03, Dave Martin <Dave.Martin@arm.com> wrote: > > > > 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. > > > > I would say that whilst it is a very dangerous thing to do and has many ptrace is inherently dangerous for the target task... that's rather the point. > consequences, there is a requirement for a gdb user to be able to change VL > whilst debugging a running process, and I don’t think we should see > changing VL as much different from changing a register value on the fly. > > Say you have a loop in assembly you are trying to debug - you might write > to $x2 and then single step to see how this effects the result. With SVE > code you might want to see how different VL values will effect the layout > of results in the vectors, how it effects the predicates and how it changes > the number of iterations the loop makes. Of course, once you exit the > loop all bets are off - just like if you had been changing register values. > > The current proposal for gdb is that we will show $VL in the list of > registers, therefore for consistency it’d make sense for the gdb user to > be able to set it as if it was just another register. For this we need a > simple way to change the VL in another process, and I think ptrace() is > the easiest way (given that prctl() only changes its own process). OK, I'll keep it for now, unless somebody has a strong objection. It doesn't affect the underlying plumbing much -- doing this via ptrace() is actually the simpler of the two options, since the task is stopped and thus less synchronisation is needed. Cheers ---Dave
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h index 1ec2363..0f1b068 100644 --- a/arch/arm64/include/asm/fpsimd.h +++ b/arch/arm64/include/asm/fpsimd.h @@ -105,6 +105,7 @@ extern void sve_load_state(void const *state, u32 const *pfpsr, extern unsigned int sve_get_vl(void); extern int sve_set_vector_length(struct task_struct *task, unsigned long vl, unsigned long flags); +extern int sve_max_vl; /* * FPSIMD/SVE synchronisation helpers for ptrace: diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h index 48b57a0..bcb542d 100644 --- a/arch/arm64/include/uapi/asm/ptrace.h +++ b/arch/arm64/include/uapi/asm/ptrace.h @@ -64,6 +64,8 @@ #ifndef __ASSEMBLY__ +#include <linux/prctl.h> + /* * User structures for general purpose, floating point and debug registers. */ @@ -108,6 +110,9 @@ struct user_sve_header { #define SVE_PT_REGS_FPSIMD 0 #define SVE_PT_REGS_SVE SVE_PT_REGS_MASK +#define SVE_PT_VL_THREAD PR_SVE_SET_VL_THREAD +#define SVE_PT_VL_INHERIT PR_SVE_SET_VL_INHERIT + /* * The remainder of the SVE state follows struct user_sve_header. The diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index 32debb8..7e40039 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -741,14 +741,15 @@ static int sve_get(struct task_struct *target, BUG_ON(!sve_vl_valid(header.vl)); vq = sve_vq_from_vl(header.vl); - /* Until runtime or per-task vector length changing is supported: */ - header.max_vl = header.vl; + BUG_ON(!sve_vl_valid(sve_max_vl)); + header.max_vl = sve_max_vl; header.flags = test_tsk_thread_flag(target, TIF_SVE) ? SVE_PT_REGS_SVE : SVE_PT_REGS_FPSIMD; header.size = SVE_PT_SIZE(vq, header.flags); - header.max_size = SVE_PT_SIZE(vq, SVE_PT_REGS_SVE); + header.max_size = SVE_PT_SIZE(sve_vq_from_vl(header.max_vl), + SVE_PT_REGS_SVE); ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, &header, 0, sizeof(header)); @@ -830,14 +831,18 @@ static int sve_set(struct task_struct *target, if (ret) goto out; - if (header.vl != target->thread.sve_vl) - return -EINVAL; - - BUG_ON(!sve_vl_valid(header.vl)); - vq = sve_vq_from_vl(header.vl); + /* + * Apart from PT_SVE_REGS_MASK, all PT_SVE_* flags are consumed by + * sve_set_vector_length(), which will also validate them for us: + */ + ret = sve_set_vector_length(target, header.vl, + header.flags & ~SVE_PT_REGS_MASK); + if (ret) + goto out; - if (header.flags & ~SVE_PT_REGS_MASK) - return -EINVAL; + /* Actual VL set may be less than the user asked for: */ + BUG_ON(!sve_vl_valid(target->thread.sve_vl)); + vq = sve_vq_from_vl(target->thread.sve_vl); /* Registers: FPSIMD-only case */
This patch adds support for manipulating a task's vector length at runtime via ptrace. As a simplification, we turn the task back into an FPSIMD-only task when changing the vector length. If the register data is written too, we then turn the task back into an SVE task, with changed task_struct layout for the SVE data, before the actual data writing is done. Because the vector length is now variable, sve_get() now needs to return the real maximum for user_sve_header.max_vl, since .vl may be less than this (that's the whole point). Signed-off-by: Dave Martin <Dave.Martin@arm.com> --- arch/arm64/include/asm/fpsimd.h | 1 + arch/arm64/include/uapi/asm/ptrace.h | 5 +++++ arch/arm64/kernel/ptrace.c | 25 +++++++++++++++---------- 3 files changed, 21 insertions(+), 10 deletions(-)