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
