Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 05 Aug 2020 12:48:51 -0700 (PDT)
Subject:     Re: [PATCH 1/2] riscv: ptrace: Use the correct API for `fcsr' access
In-Reply-To: <alpine.LFD.2.21.2008051117180.24175@redsun52.ssa.fujisawa.hgst.com>
CC:     viro@zeniv.linux.org.uk, linux-riscv@lists.infradead.org,
        Paul Walmsley <paul.walmsley@sifive.com>,
        aou@eecs.berkeley.edu, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org
From:   Palmer Dabbelt <palmer@dabbelt.com>
To:     macro@wdc.com
Message-ID: <mhng-6e42b0e6-1f3b-41a3-a023-4145fb4d8980@palmerdabbelt-glaptop1>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 05 Aug 2020 03:25:11 PDT (-0700), macro@wdc.com wrote:
> 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));
>> 	membuf_store(&to, fstate->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
> feature nowadays.

IIRC Andrew does GDB test suite runs sometimes natively on Linux as part of
general GDB maintiance and we don't see major issues, but I'm pretty checked
out of GDB development these days so he would know better than I do.  It's
always great to have someone test stuff, though -- and I doubt he's testing
linux-next.  It's been on my TODO list for a long time now to put together
tip-of-tree testing for the various projects but I've never gotten around to
doing it.

Oddly enough, despite not really using GDB I have used it for core dumps -- I
was writing a tool to convert commit logs to coredumps with the GDB reverse
debugging annotations, but I never got around to finishing it.