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