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 -- Cheers, Changbin Du
