Without that commit, I can set breakpoints and debug 32 bit code AND 64 bit code just fine in the same debug session...
"set arch" does nothing to remedy my problems. I cannot even set breakpoints before the system runs, let alone after I interrupt it... Are you sure this approach is needed? I have no such problems with bochs... On Thu, Sep 16, 2010 at 7:55 PM, Jan Kiszka <jan.kis...@web.de> wrote: > Am 14.09.2010 07:48, Ted Harkington wrote: > > Hello, > > > > I have been trying to figure out why I cannot debug a 64 bit kernel of my > > own invention. > > > > I launch qemu-system-x86_64 with the -s -S flags, we also specify -cpu > > core2duo -vga std and a -hda with an ext2 FS holding our multiboot kernel > > and GRUB2. > > > > When I try to set breakpoints and "continue" in GDB (7.2) using the very > > latest HEAD (b6601141cd2a170dfe773987b06f716a190ea7e0) or 0.12.0 or > 0.12.5 > > or 13.0.rc0 or 13.0.rc1, I get failures of the same nature: > > > > 0x0000000000000000 in ?? () > > (gdb) break main > > Breakpoint 1 at 0x101730: file src/kernel/init.c, line 18. > > (gdb) c > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x0000000000000000 in ?? () > > (gdb) > > > > Note that in this case, main lies in 64 bit mode. However, trying to > break > > on _start yields virtually the same effect and _start is 32 bit code. > > > > By doing a git bisect, I managed to narrow the commit that introduced > this > > bug to 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1. Reverting this commit on > > HEAD seemingly fixed the problem for both the 32 bit and 64 bit cases. > > I might be doing something incorrectly on my end but this seemed to fix > the > > problem. > > > > Perhaps the pertinent thing to do would be to > > revert 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 as it seems to do nothing > > but break things unless, of course, this would only break something that > I > > am not aware of further. > > Without that commit, you won't be able to debug guest code in 32- or > 16-bit mode with qemu-system-x86_64. The reason is the limited remote > gdb protocol that cannot handle mode switches. The commit works around > this by switching the architecture instead - which is far from being > elegant but still the only alternative. > > Do you have to debug across a mode switch or just set a proper > breakpoint in 64-bit land? In the latter case, just interrupt your guest > when it is running 64 bits, then set your breakpoints. If that was too > late, issue a system_reset and let the breakpoints trap on second run. > > If you need to debug the mode switch itself, things get hairy as gdb > sometimes dislikes to follow the architecture change via "set arch > i386...". > > Jan > >
