[v2] RISC-V: Add ptrace support for vectors

[Thorsten Leemhuis]

On 31.08.23 19:17, Conor Dooley wrote:
> On Thu, Aug 31, 2023 at 10:05:04AM -0700, Nick Desaulniers wrote:
>> On Fri, Aug 25, 2023 at 05:02:46AM +0000, Andy Chiu wrote:
>>> This patch add back the ptrace support with the following fix:
>>>  - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
>>>    conflicting with gdb's NT_RISCV_CSR.
>>>  - Use struct __riscv_v_regset_state to handle ptrace requests
>>>
>>> Since gdb does not directly include the note description header in
>>> Linux and has already defined NT_RISCV_CSR as 0x900, we decide to
>>> sync with gdb and renumber NT_RISCV_VECTOR to solve and prevent future
>>> conflicts.
>>>
>>> Fixes: 0c59922c769a ("riscv: Add ptrace vector support")
>>> Signed-off-by: Andy Chiu <andy.chiu at sifive.com>
>>
>> Hi Andy, this is causing an instance of -Wunused-variable. PTAL.
>>
>> Please use the following tags on the fix:
>>
>> Reported-by: "kernelci.org bot" <bot at kernelci.org>
>> Closes: https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/
>>
>> Let's see if I can get the regzbot tag correct; first time trying it.
>> #regzbot introduced dbe46b094026

Nick, thx for trying, but FWIW, that's was slightly off, but there might
be a easy workaround. To explain for anyone that cares:

Due to that '#regzbot introduced ...' regzbot will consider the mail
with the "#regzbot introduced dbe46b094026" (e.g. the msg from Nick with
the msgid ZPDIQEVaEJHXR5IW at google.com) as a report for this regression
and thus look out for patches and commits with a tag like this:

 Closes: https://lore.kernel.org/all/ZPDIQEVaEJHXR5IW@google.com/

Which is kinda correct, as your mail *is* a report about the regression,
so some developer might use this. But in this case that's not what Nick
wanted, as there was an earlier report that was even specified. But
well, that might make it easy to fix, as we could simply tell regzbot
about the duplicate. Nick could have done that in his mail, but I can do
it in this one was well (as it's a indirect reply to the report from
Nick that regzbot track) that 64f03ea1.170a0220.d3dbf.11fd at mx.google.com
is a duplicate of ZPDIQEVaEJHXR5IW at google.com:

#regzbot dup-of:
https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/

Let's see if this works. I haven't used this much, so maybe something
might go sideways; but in theory this should work and then regzbot would
do the right thing. At least normally:

> See <20230830203754.24940-1-palmer at rivosinc.com> for the fix.
> 
> That has you gave regzbot prob won't be stable though, branch needs a
> rebase to add missing SoB tags from its committer.

You mean the commit-id of the change currently known as dbe46b094026
will change? Ughh, yeah, that's unfortunate and something regzbot is not
yet prepared for.

Hmmmm. Haven't had this case yet, as regzbot until now is not used much
for -next. Not sure how to best handle that. Sure, regzbot could notice
"the commit formerly known as cafec0c0 is now now c0c0cafe, as the
subject, author, and modified files roughly match" -- but I'm not sure
if that's a good idea, as developers like Conor might integrate simple
fixes like the one for the problem at hand during the rebase. So maybe
at this point it becomes "some human needs to look into this and tell
regzbot what to do". :-/

Ciao, Thorsten