From: Dave Martin <Dave.Martin@arm.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: linux-arch@vger.kernel.org, Florian Weimer <fweimer@redhat.com>,
libc-alpha@sourceware.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Marc Zyngier <Marc.Zyngier@arm.com>,
gdb@sourceware.org, Joseph Myers <joseph@codesourcery.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
linux-arm-kernel@lists.infradead.org,
Alan Hayward <alan.hayward@arm.com>,
Torvald Riegel <triegel@redhat.com>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting
Date: Mon, 16 Jan 2017 13:32:31 +0000 [thread overview]
Message-ID: <20170116133231.GO3699@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20170116122038.GG28060@E107787-LIN>
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
WARNING: multiple messages have this Message-ID (diff)
From: Dave.Martin@arm.com (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting
Date: Mon, 16 Jan 2017 13:32:31 +0000 [thread overview]
Message-ID: <20170116133231.GO3699@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20170116122038.GG28060@E107787-LIN>
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
next prev parent reply other threads:[~2017-01-16 13:32 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-12 11:25 [RFC PATCH 00/10] arm64/sve: Add userspace vector length control API Dave Martin
2017-01-12 11:25 ` Dave Martin
2017-01-12 11:25 ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 01/10] prctl: Add skeleton for PR_SVE_{SET,GET}_VL controls Dave Martin
2017-01-12 11:26 ` [RFC PATCH 01/10] prctl: Add skeleton for PR_SVE_{SET, GET}_VL controls Dave Martin
2017-01-12 11:26 ` [RFC PATCH 02/10] arm64/sve: Track vector length for each task Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 03/10] arm64/sve: Set CPU vector length to match current task Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 04/10] arm64/sve: Factor out clearing of tasks' SVE regs Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 05/10] arm64/sve: Wire up vector length control prctl() calls Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 06/10] arm64/sve: Disallow VL setting for individual threads by default Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-16 11:34 ` Yao Qi
2017-01-16 11:34 ` Yao Qi
2017-01-16 12:23 ` Dave Martin
2017-01-16 12:23 ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 07/10] arm64/sve: Add vector length inheritance control Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-16 12:27 ` Yao Qi
2017-01-16 12:27 ` Yao Qi
2017-01-16 13:34 ` Dave Martin
2017-01-16 13:34 ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-16 12:20 ` Yao Qi
2017-01-16 12:20 ` Yao Qi
2017-01-16 13:32 ` Dave Martin [this message]
2017-01-16 13:32 ` Dave Martin
2017-01-16 15:11 ` Yao Qi
2017-01-16 15:11 ` Yao Qi
2017-01-16 15:47 ` Pedro Alves
2017-01-16 15:47 ` Pedro Alves
2017-01-16 16:31 ` Dave Martin
2017-01-16 16:31 ` Dave Martin
2017-01-17 10:03 ` Dave Martin
2017-01-17 10:03 ` Dave Martin
2017-01-17 13:31 ` Alan Hayward
2017-01-17 13:31 ` Alan Hayward
2017-01-19 17:11 ` Dave Martin
2017-01-19 17:11 ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 09/10] arm64/sve: Enable default vector length control via procfs Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 10/10] Revert "arm64/sve: Limit vector length to 512 bits by default" Dave Martin
2017-01-12 11:26 ` Dave Martin
2017-01-12 11:26 ` Dave Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170116133231.GO3699@e103592.cambridge.arm.com \
--to=dave.martin@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=alan.hayward@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=christoffer.dall@linaro.org \
--cc=fweimer@redhat.com \
--cc=gdb@sourceware.org \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=qiyaoltc@gmail.com \
--cc=szabolcs.nagy@arm.com \
--cc=triegel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.