Re: [Qemu-devel] Adding another debug protocol

[Jan Kiszka]

On 2012-11-15 02:58, Peter Cheung wrote:
>> Date: Wed, 14 Nov 2012 17:43:12 +0100
>> From: address@hidden
>> To: address@hidden
>> CC: address@hidden; address@hidden
>> Subject: Re: [Qemu-devel] Adding another debug protocol
>>
>> On 2012-11-14 17:28, Peter Cheung wrote:
>>> hi Jan, you are the maintainer of the gdb server of qemu?
>>
>> Not formally. I'm heavily using it for kernel debugging for a couple of
>> years. Therefore, I'm fixing and enhancing it from time to time.
>>
>>> I think if I can't create my debug protocol, it is not easy to adopt 
>>> peter-bochs debugger to qemu, in peter-bochs, there are some features I 
>>> think current gdb protocol doesn't care, such as profiling, kernel module 
>>> monitoring, call graph history, real time address probeing.
>>> I know qemu is made by a lots of people, seems not easy to convince 
>>> everyone.
>>
>> A good general rule, not only in open source, is to at least try to fix
>> existing infrastructure. If that fails provably, you can come up with a
>> new version to replace or augment things.
>>
>> E.g., you didn't explain yet why the gdb protocol and our existing stub
>> cannot be extended in a backward compatible way that allows your
>> debugger to attach to it. That way not only your debugger (is it Windows
>> hosted?) could benefit from the improvements but the whole (x86) gdb world.
>>
>> Jan
>>
>> PS: Please don't top-post, cite what you comment on.
>>
>> -- 
>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>> Corporate Competence Center Embedded Linux
>>
> 
> sorry the top-posting, hotmail and gmail just changed to top-post years ago.
> In GDB protocol, they don't have a repeat command, when i do profiling my 
> kernel, let's say 10 mins, i probably need to send 100,000 "s" command to 
> gdb, i think this will slow down the qemu, this already happen.

GDB tracepoints are able to model this. They are set up over the remote
protocol, thus the events themselves can be handled on the server side
only, here inside QEMU or KVM. That takes the latency of the remote
protocol out of the loop. If you browse the archive here, you'll see
that I proposed this already and someone even did a prototype.

> In GDB, i don't know how to set a pbreakpoint (physical address), breakpoint 
> (linear address). I guess gdb is natural to all cpu platforms, so they don't 
> provide this x86-specified breakpoint setting.

It will be trivial to extend the existing breakpoint command (Z0..4) by
another mode that means "watch physical memory access" and teach this
also to gdb. A gdb server does not have to support all modes, thus it's
fine if QEMU would be the only provider initially.

> If really not possible to add this feature, can we do it : i compile all my 
> code into an .a file, and qemu dynamically load it? then i don't need to 
> modify the qemu source.

Plugins are a hot topic in the QEMU project. Your example won't be a
good candidate to motivate them. Also, we heard no technical reasons so
far for introducing a complete new protocol at all.

Jan

signature.asc
Description: OpenPGP digital signature