On Tue, Aug 04, 2020 at 07:20:05PM -0700, Palmer Dabbelt wrote:
> On Tue, 04 Aug 2020 19:07:45 PDT (-0700), v...@zeniv.linux.org.uk wrote:
> > On Tue, Aug 04, 2020 at 07:01:01PM -0700, Palmer Dabbelt wrote:
> >
> > > > We currently have @start_pos fixed at 0 across all calls, which works as
> > > > a result of the implementation, in particular because we have no padding
> > > > between the FP general registers and the FP control and status register,
> > > > but appears not to have been the intent of the API and is not what other
> > > > ports do, requiring one to study the copy handlers to understand what is
> > > > going on here.
> >
> > start_pos *is* fixed at 0 and it's going to go away, along with the
> > sodding user_regset_copyout() very shortly. ->get() is simply a bad API.
> > See vfs.git#work.regset for replacement. And ->put() is also going to be
> > taken out and shot (next cycle, most likely).
>
> 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));
membuf_store(&to, fstate->fcsr);
return membuf_zero(&to, 4); // explicitly pad
}
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.
