qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Commit 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 breaks


From: Jan Kiszka
Subject: [Qemu-devel] Re: Commit 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 breaks debugging 64 bit guests
Date: Sun, 19 Sep 2010 00:23:24 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]