Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 19 Aug 2020 21:00:46 +0100 (BST) | From | "Maciej W. Rozycki" <> | Subject | Re: [PATCH 1/2] riscv: ptrace: Use the correct API for `fcsr' access |
| |
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
| ![\](/images/icornerr.gif) |