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;
IronPort-SDR: vhsi6WmrJ7uoCStof2WRmBXZL1Axfa4kjHuO/aAWJdg8iBTEuQyHgYI8ylCESQ9OabQAHQIfyK
 WKeIDvbkWfASy6mz179hx7GyQby1kPDdRjNac3DgtTHwNbHjqXsElh24C6Upyjx00xmHthy6hy
 kvSFtnnn51fUClwJaTKD3qpa9cEPaJqneJCrxAeAcHMPO/iPVRGd27nutf0mC+2z4p5YUGzGoQ
 G8VBelJBTsb9DCVSWLxiedIRfQTMxnh267gLVHI+DldxwQeOuasOGKFx6KP6Pkwf19EJXgvPYX
 z3U=
IronPort-SDR: 85AtiEJc3UwCZU8SCbF1XXG2j55Vh5hd6N/Rz8WnN4tZGIA4jSZAO6iCqNNli2QjI75MSfmvHF
 JsPIIXEokGVA==
IronPort-SDR: lgC0qzfmt+LZzgs6kv/HBx4AvEFDNKPlHG7WS3l2eueThUpIpnLKMnCur05odAaPlQfkGCiGdB
 +xazf3+SHAFw==
WDCIronportException: Internal
Date:   Wed, 19 Aug 2020 21:00:46 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@wdc.com>
To:     Palmer Dabbelt <palmer@dabbelt.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
Subject: Re: [PATCH 1/2] riscv: ptrace: Use the correct API for `fcsr'
 access
In-Reply-To: <mhng-6e42b0e6-1f3b-41a3-a023-4145fb4d8980@palmerdabbelt-glaptop1>
Message-ID: <alpine.LFD.2.21.2008190019480.24175@redsun52.ssa.fujisawa.hgst.com>
References: <mhng-6e42b0e6-1f3b-41a3-a023-4145fb4d8980@palmerdabbelt-glaptop1>
User-Agent: Alpine 2.21 (LFD 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 5 Aug 2020, Palmer Dabbelt wrote:

> >  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.

 I have now run GDB regression testing with remote `gdbserver' on a HiFive 
Unleashed, lp64d ABI only, comparing 5.8.0-next-20200814 against 5.8.0-rc5 
with no issues observed.

> 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.

 I fiddled with core dump handling verification for GDB back in my MIPS 
days expanding an existing test case to interpret an OS-generated core 
dump in addition to one produced by GDB's `gcore' command, although in the 
case of local testing only (i.e. either native or running `gdbserver' on 
the same test machine GDB runs); this restriction is due to the need to 
isolate the core file produced, as it may or may not have a .$pid suffix 
attached (or may have yet another name variation with non-Linux targets), 
which is somewhat complicated with commands run remotely (though I imagine 
the restriction could be lifted by someone sufficiently inclined).

 The relevant tests results are as follows (on a successful run):

PASS: gdb.threads/tls-core.exp: native: load core file
PASS: gdb.threads/tls-core.exp: native: print thread-local storage variable
PASS: gdb.threads/tls-core.exp: gcore: load core file
PASS: gdb.threads/tls-core.exp: gcore: print thread-local storage variable

and the binutils-gdb change is commit d9f6d7f8b636 ("testsuite: Extend TLS 
core file testing with an OS-generated dump").  So that part should be 
covered at least to some extent by automated testing.

 However something is not exactly right and I recall having an issue 
recorded for later investigation (which may not happen given the recent 
turn of events) that RISC-V/Linux does not actually dump cores even in the 
circumstances it is supposed to (i.e. the combination of the specific 
signal delivered and RLIMIT_CORE set to infinity imply it).

 Indeed I have run the test natively now and I got:

PASS: gdb.threads/tls-core.exp: successfully compiled posix threads test case
WARNING: can't generate a core file - core tests suppressed - check ulimit -c
PASS: gdb.threads/tls-core.exp: gcore
UNSUPPORTED: gdb.threads/tls-core.exp: native: load core file
UNSUPPORTED: gdb.threads/tls-core.exp: native: print thread-local storage variable
PASS: gdb.threads/tls-core.exp: gcore: load core file
PASS: gdb.threads/tls-core.exp: gcore: print thread-local storage variable

which means things are not actually sound.  Likewise if I run the test 
program manually:

$ ulimit -c
unlimited
$ ./tls-core
Aborted (core dumped)
$ ls -la core*
ls: cannot access 'core*': No such file or directory
$ 

-- oops!

 [As it turned out MIPS core dump handling was completely messed up both 
on the Linux and the GDB side.  See binutils-gdb commit d8dab6c3bbe6 
("MIPS/Linux: Correct o32 core file FGR interpretation") if interested; 
there are further Linux commit references there.]

  Maciej