Re: [PATCH 1/2] riscv: ptrace: Use the correct API for `fcsr' access

[Maciej W. Rozycki]

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