Re: [Qemu-devel] Re: About QEMU debugging console

[Jan Kiszka]

Am 29.10.2010 04:41, Zhiyuan Shao wrote:
> On Thu, 2010-10-28 at 14:36 +0200, Jan Kiszka wrote:
>> Am 26.10.2010 14:22, Zhiyuan Shao wrote:
>>> Hi team,
>>>
>>> I am a Qemu User, and using Qemu 0.13.0 to debugging the linux kernel
>>> code (Qemu+GDB). 
>>>
>>> During the usage, I found the Qemu debugging console (i.e., entered by
>>> pressing Ctl+Alt+2 in Qemu SDL window or by passing "-monitor stdio" to
>>> Qemu in the command line) is rather difficult to use. 
>>
>> Regarding usability in this scenario: You know that there is QEMU
>> monitor pass-through via gdb "monitor" command?
>>
> Yes, Just learned to use that. By gdb "monitor" command, the output of
> QEMU debugging console is redirected to gdb. 
> 
>>> It can not show
>>> some important information, e.g., on i386 platform, which is my major
>>> interest, it can not show IDT, GDT information. Regarding the page
>>> mapping information, "info tlb" actually do a really bad job. 
>>>
>>> On this side, I think Bochs is good. Unfortunately, it seems do not
>>> support gdb-stub debugging and general purpose debugging at the same
>>> time.
>>>
>>> I do not know if the Qemu team had made any plans to improve this? such
>>> as embedding the bochs debugging alike functionalities in future Qemu
>>> releases?
>>
>> The most important lacking feature is proper system-level debugging
>> support for gdb (via gdbstub). Once gdb has full access to all CPU
>> states of the x86 targets, you can pretty-print whatever you want inside
>> gdb via some nice Python scripts etc.
>>
> Are you mean that it is the responsibility of gdb to parse the output
> data of qemu built-in commands and generate user-friend output? Or grant
> gdb full access to the target machine, which is emulated by Qemu, and it
> is the responsibility of gdb again to generate easy-to-read output for
> the users?

More the latter: The full register set (including MSRs) need to be made
available to gdb via the remote protocol, and gdb has to be taught
interpreting it. This is e.g. required to understand the current
operating mode (16/32/64 bit) and legacy segmentation.

Moreover, once you have access to the control registers (and some MSRs),
you can easily parse and dump the page table hierarchy in gdb extension
scripts (preferably in Python these days). That's way better than
overloading QEMU with more of such things.

> 
> I think the first solution sounds more feasible, however, we still need
> more helpful built-in commands in Qemu. 
> And it is hard to implement the second solution: By doing this, we may
> need to have full support from GDB community. 

For sure. But the major issue is more about resources to work on this
than gdb community support. Browse their mailing list archive to find
that they are actually supportive regarding this topic.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux