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