On Wed, 5 Aug 2020, Al Viro wrote:
> I'm not sure I understand what you're saying, but given that branch replaces
> all of this I guess it's best to just do nothing on our end here?
It doesn't replace ->put() (for now); it _does_ replace ->get() and AFAICS the
replacement is much saner:
static int riscv_fpr_get(struct task_struct *target,
const struct user_regset *regset,
struct membuf to)
struct __riscv_d_ext_state *fstate = &target->thread.fstate;
membuf_write(&to, fstate, offsetof(struct __riscv_d_ext_state, fcsr));
return membuf_zero(&to, 4); // explicitly pad
I'm glad to see the old interface go, it was cumbersome.
user_regset_copyout() calling conventions are atrocious and so are those of
regset ->get(). The best thing to do with both is to take them out of their
misery and be done with that. Do you see any problems with riscv gdbserver
on current linux-next? If not, I'd rather see that "API" simply go away...
If there are problems, I would very much prefer fixes on top of what's done
in that branch.
I can push linux-next through regression-testing with RISC-V gdbserver
and/or native GDB if that would help. This is also used with core dumps,
but honestly I don't know what state RISC-V support is in in the BFD/GDB's
core dump interpreter, as people tend to forget about the core dump