mbox series

[-next,0/2] riscv: ptrace: implement PTRACE_{PEEK,POKE}USR

Message ID 20220822030105.16053-1-zouyipeng@huawei.com (mailing list archive)
Headers show
Series riscv: ptrace: implement PTRACE_{PEEK,POKE}USR | expand

Message

Yipeng Zou Aug. 22, 2022, 3:01 a.m. UTC
The PTRACE_{PEEK,POKE}USR going to get/set tracee's user register.
This patch sets add PTRACE_{PEEK,POKE}USR and compat implement to
riscv.

I notice this issuse when transplanting some app form x86 to riscv
recently.
I don't know why these two function are not implemented now, and I
found few talk about that.

The {PEEK,POKE}USR are both defined in include\uapi\linux\ptrace.h,
So I was thinking maybe these two function shouled be implemented.

Yipeng Zou (2):
  riscv: ptrace: Implement PTRACE_{PEEK,POKE}USR
  riscv: ptrace: Implement Compat PTRACE_{PEEK,POKE}USR

 arch/riscv/include/asm/compat.h |  13 ++++
 arch/riscv/kernel/ptrace.c      | 111 ++++++++++++++++++++++++++++++++
 2 files changed, 124 insertions(+)

Comments

Andreas Schwab Aug. 22, 2022, 8:19 a.m. UTC | #1
On Aug 22 2022, Yipeng Zou wrote:

> The PTRACE_{PEEK,POKE}USR going to get/set tracee's user register.
> This patch sets add PTRACE_{PEEK,POKE}USR and compat implement to
> riscv.
>
> I notice this issuse when transplanting some app form x86 to riscv
> recently.
> I don't know why these two function are not implemented now, and I
> found few talk about that.
>
> The {PEEK,POKE}USR are both defined in include\uapi\linux\ptrace.h,
> So I was thinking maybe these two function shouled be implemented.

There are PTRACE_[GS]ETREGSET.  I think PTRACE_{PEEK,POKE}USR are
legacy-only.
Palmer Dabbelt Oct. 6, 2022, 1:26 a.m. UTC | #2
On Mon, 22 Aug 2022 01:19:03 PDT (-0700), schwab@suse.de wrote:
> On Aug 22 2022, Yipeng Zou wrote:
>
>> The PTRACE_{PEEK,POKE}USR going to get/set tracee's user register.
>> This patch sets add PTRACE_{PEEK,POKE}USR and compat implement to
>> riscv.
>>
>> I notice this issuse when transplanting some app form x86 to riscv
>> recently.
>> I don't know why these two function are not implemented now, and I
>> found few talk about that.
>>
>> The {PEEK,POKE}USR are both defined in include\uapi\linux\ptrace.h,
>> So I was thinking maybe these two function shouled be implemented.
>
> There are PTRACE_[GS]ETREGSET.  I think PTRACE_{PEEK,POKE}USR are
> legacy-only.

That's my understanding as well.  Anything ported to RISC-V would need 
to understand the new register formats, so there's not much benefit to 
supporting these old flavors of register twiddling -- maybe some 
refactoring needs to be done in userspace to take advantage of accessing 
multiple registers at the same time, but that should probably be done 
anyway as all ports support the new interfaces these days.

There's been a few rounds of these having been posted, maybe that means 
the documentation should be improved?  I sent 
<https://lore.kernel.org/r/20221006012432.19008-1-palmer@rivosinc.com/>, 
that'll also help sort out whether we're supposed to have these.
Yipeng Zou Oct. 8, 2022, 1:24 a.m. UTC | #3
在 2022/10/6 9:26, Palmer Dabbelt 写道:
> On Mon, 22 Aug 2022 01:19:03 PDT (-0700), schwab@suse.de wrote:
>> On Aug 22 2022, Yipeng Zou wrote:
>>
>>> The PTRACE_{PEEK,POKE}USR going to get/set tracee's user register.
>>> This patch sets add PTRACE_{PEEK,POKE}USR and compat implement to
>>> riscv.
>>>
>>> I notice this issuse when transplanting some app form x86 to riscv
>>> recently.
>>> I don't know why these two function are not implemented now, and I
>>> found few talk about that.
>>>
>>> The {PEEK,POKE}USR are both defined in include\uapi\linux\ptrace.h,
>>> So I was thinking maybe these two function shouled be implemented.
>>
>> There are PTRACE_[GS]ETREGSET.  I think PTRACE_{PEEK,POKE}USR are
>> legacy-only.
>
> That's my understanding as well.  Anything ported to RISC-V would need 
> to understand the new register formats, so there's not much benefit to 
> supporting these old flavors of register twiddling -- maybe some 
> refactoring needs to be done in userspace to take advantage of 
> accessing multiple registers at the same time, but that should 
> probably be done anyway as all ports support the new interfaces these 
> days.
>
ok, got it.
> There's been a few rounds of these having been posted, maybe that 
> means the documentation should be improved?  I sent 
> <https://lore.kernel.org/r/20221006012432.19008-1-palmer@rivosinc.com/>, 
> that'll also help sort out whether we're supposed to have these.