[Qemu-devel] Commit 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 breaks debugging 64 bit guests

[Qemu-devel] Commit 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 breaks debugging 64 bit guests

[Ted Harkington]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

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.

-- 
Ted

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

[Qemu-devel] Re: Commit 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 breaks debugging 64 bit guests

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

[Qemu-devel] Re: Commit 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 breaks debugging 64 bit guests

[Ted Harkington]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

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.kiszka@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
>
>

[-- Attachment #2: Type: text/html, Size: 3360 bytes --]

[Qemu-devel] Re: Commit 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 breaks debugging 64 bit guests

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

Am 18.09.2010 23:23, Ted Harkington wrote:
> Without that commit, I can set breakpoints and debug 32 bit code AND 64 bit
> code just fine in the same debug session...

Then gdb will then debug 32-bit code in 64-bit mode as that's the
architecture in use. That's not seriously usable if you look closer.

> 
> "set arch" does nothing to remedy my problems.
> 
> I cannot even set breakpoints before the system runs, let alone after I
> interrupt it...

gdb does not support setting a 64-bit breakpoints when debugging a 16-
or 32-bit target, and vice versa. As I said, you need to interrupt your
guest while in 64-bit mode, set your breakpoint and reset the guest if
it passed it already.

> 
> Are you sure this approach is needed? I have no such problems with bochs...

It is mandatory for source-level debugging. E.g. stack backtraces in 16
or 32-bit mode are broken otherwise.

The problem is that gdb has no clue about the processor mode in use on
the target. It derives it from the target architecture which is OK for
application debugging (and that's what gdb is still designed for) but
it's insufficient for system-level debugging. I don't know how bochs
deals with this, but it faces the very same gdb limitation.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]