On Thu, Feb 20, 2020 at 10:24:37PM +0100, Luc Michel wrote:
I'm curious, I never experienced this behaviour from GDB. What GDB and
QEMU versions are you using?
On my side (GDB 9.1), even without 'vContSupported+' in the 'qSupported'
answer, GDB sends a 'vCont?' packet on the first stepi:
0x00000000 in ?? ()
(gdb) si
Sending packet: $m0,4#fd...Ack
Packet received: 00000000
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C;s;S
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;s:p1.1;c:p1.-1#f7...Ack
Packet received: T05thread:p01.01;
Your second issue (wrong PC value) should be investigated though. Does
it happen on QEMU vanilla? Do you have a way to reproduce this bug?
Just confirmed this issue. This is an endianness problem for gdb. I was
debugging an big-endian elf and my host cpu is little-endian. QEMU gdbstub
always uses host cpu endian but gdb client treats it as big-endian by
inspecting elf info.
I can mannually set it to little-endian but it is painful. The gdb complains
abount invalid opcode error in debuginfo.
I also noticed that someoneelse has already tried to resolve this issue.
https://patchwork.kernel.org/patch/9528947/
Anyway after re-reading the GDB remote protocol documentation, I think
your patch is right, the feature should be advertised.
However I think your commit message needs some modifications. This fix
is not specific to ARM or TCG, but to the gdbstub itself. You also
mention this bug you have with PC, which is not related to the bug you
are fixing here. Could you rewrite it in a more generic way? You simply
need to emphasis the effect of advertising the 'vContSupported+' feature
on GDB.
Thanks.
--
Luc