gdb-multiarch 8.1.1-0ubuntu1: assertion failure or internal error when connecting to QEMU aarch64 gdbstub

[Peter Maydell]

This bug is a regression introduced in 8.1.1-0ubuntu1 for Bionic -- the previous 8.1-0ubuntu3.2 gdb works fine with QEMU's gdbstub.

Reproduce:
Get the sources for QEMU 5.2.0, and build the aarch64-linux-user target. (It looks like Bionic's QEMU is old enough that it doesn't provoke this gdb error.)

Run
 qemu-aarch64 -g 1234 path/to/some/aarch64/binary

In another terminal, start gdb-multiarch. At the (gdb) prompt, type "target remote :1234". GDB will dump core:

(gdb) target remote :1234
Remote debugging using :1234
Recursive internal problem.
Aborted (core dumped)

You can see a variant of this also in the QEMU test suite with "make -C your-qemu-build-dir check-tcg", where the error message includes an assertion failure:

[...]

timeout 60 /home/petmay01/linaro/qemu-from-laptop/qemu/tests/guest-debug/run-test.py --gdb /usr/bin/gdb-multiarch --qemu /home/petmay01/linaro/qemu-from-laptop/qemu/build/aarch64-linux/qemu-aarch64 --qargs "" --bin sha1 --test /home/petmay01/linaro/qemu-from-laptop/qemu/tests/tcg/multiarch/gdbstub/sha1.py > run-gdbstub-sha1.out
/build/gdb-veKdC1/gdb-8.1.1/gdb/regcache.c:122: internal-error: void* init_regcache_descr(gdbarch*): Assertion `MAX_REGISTER_SIZE >= descr->sizeof_register[i]' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

This is a bug, please report it. For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

Aborted (core dumped)
/home/petmay01/linaro/qemu-from-laptop/qemu/tests/tcg/multiarch/Makefile.target:51: recipe for target 'run-gdbstub-sha1' failed

[Peter Maydell (pmaydell)]

Further testing with the old gdb-8.1-0ubuntu3 package shows that this isn't a regression since then, as that version fails too. I must have been misled by the apt history.log somehow; sorry for the confusion there.

[Peter Maydell (pmaydell)]

It looks like the reason QEMU's test suite passed was that the older Ubuntu gdb didn't have a fix for LP:1901026 (support remote connection over UNIX domain socket), so the test suite would simply skip the offending test and never get as far as falling over the assertion failure. After pulling various old binaries out of my backups to test I'm forced to conclude that I was simply misremembering by-hand use of the gdbstub working and I must not have used it as recently as I'd thought. So this is a bug, but not a regression.

A possible set of commits for a cherry-picked fix would be c8ec2f334c3751c28d5f and 4ef0bef68cfc777e59156fce1 (which together remove the hard-coded limit on register size and thus also the assertion), but the former is not a completely trivial patch. I haven't attempted such a cherry-pick to see if it works.

A workaround is to tell QEMU not to emulate SVE (eg with "-cpu max,sve=off" -- it is the large SVE vector registers which trigger the problem.