[Qemu-devel] Adding another debug protocol

[Qemu-devel] Adding another debug protocol

[Peter Cheung]

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

Dear All    I am going to add another debugger server into QEMU, so i need to1) create another socket server, similar than gdbserver, to receive the command from debugger2) add another option, such as "--start-debugger-server" to start the socket server.
After I work out the whole thing, how can i ask for the qemu maintainer to accept my code? I believe i should write a proposal first.

Thanksfrom Peter 		 	   		  

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

Re: [Qemu-devel] Adding another debug protocol

[Peter Maydell]

On 14 November 2012 10:45, Peter Cheung <mcheung63@hotmail.com> wrote:
> Dear All
>     I am going to add another debugger server into QEMU, so i need to
> 1) create another socket server, similar than gdbserver, to receive the
> command from debugger
> 2) add another option, such as "--start-debugger-server" to start the socket
> server.
>
> After I work out the whole thing, how can i ask for the qemu maintainer to
> accept my code? I believe i should write a proposal first.

Probably worth including a summary of why your second debug protocol
couldn't be implemented as a translation layer between gdbserver
protocol and whatever it is you need.

-- PMM

Re: [Qemu-devel] Adding another debug protocol

[Peter Cheung]

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

Hi   Cannot use gdb protocol, because it is slow.Also, the original gdb stub can dump out GDT/IDT/CR0 directly.

Thanksfrom Peter

> Date: Wed, 14 Nov 2012 10:54:02 +0000
> From: peter.maydell@linaro.org
> To: mcheung63@hotmail.com
> CC: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] Adding another debug protocol
> 
> On 14 November 2012 10:45, Peter Cheung <mcheung63@hotmail.com> wrote:
> > Dear All
> >     I am going to add another debugger server into QEMU, so i need to
> > 1) create another socket server, similar than gdbserver, to receive the
> > command from debugger
> > 2) add another option, such as "--start-debugger-server" to start the socket
> > server.
> >
> > After I work out the whole thing, how can i ask for the qemu maintainer to
> > accept my code? I believe i should write a proposal first.
> 
> Probably worth including a summary of why your second debug protocol
> couldn't be implemented as a translation layer between gdbserver
> protocol and whatever it is you need.
> 
> -- PMM
> 
 		 	   		  

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

Re: [Qemu-devel] Adding another debug protocol

[Jan Kiszka]

On 2012-11-14 15:40, Peter Cheung wrote:
> Hi   Cannot use gdb protocol, because it is slow.

For any practical purpose I came across so far while debugging guest
kernels, that is not true when running against QEMU. Sure, if you want
to dump gigabytes of RAM this way, it will be a bottleneck. But when do
you have to do this while interactively debugging? Printing the content
will still take longer than transmitting it.

> Also, the original gdb stub can dump out GDT/IDT/CR0 directly.

That is true, but it should be addressed in gdb. Folks there are aware
of the issue and will happily discuss extension proposals and likely
also take the necessary patches. It will be trivial to adapt QEMU to
such an extension afterward.

Also, this is a temporary, just too long pending issue for x86. I'm not
aware of such limitations for other architectures.

And there is actually workaround for the meantime: issue "monitor info
registers" in the gdb session to obtain also those registers. "monitor
cpu N" will allow you to switch between CPUs. It's not nice but saved my
days a few times already.

Jan

> 
> Thanksfrom Peter
> 
>> Date: Wed, 14 Nov 2012 10:54:02 +0000
>> From: peter.maydell@linaro.org
>> To: mcheung63@hotmail.com
>> CC: qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] Adding another debug protocol
>>
>> On 14 November 2012 10:45, Peter Cheung <mcheung63@hotmail.com> wrote:
>>> Dear All
>>>     I am going to add another debugger server into QEMU, so i need to
>>> 1) create another socket server, similar than gdbserver, to receive the
>>> command from debugger
>>> 2) add another option, such as "--start-debugger-server" to start the socket
>>> server.
>>>
>>> After I work out the whole thing, how can i ask for the qemu maintainer to
>>> accept my code? I believe i should write a proposal first.
>>
>> Probably worth including a summary of why your second debug protocol
>> couldn't be implemented as a translation layer between gdbserver
>> protocol and whatever it is you need.
>>
>> -- PMM
>>
>  		 	   		  
> 

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Adding another debug protocol

[Peter Cheung]

hi Jan, you are the maintainer of the gdb server of qemu?
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.

從我的 iPad 傳送

"Jan Kiszka" <jan.kiszka@siemens.com> 於 2012年11月14日 下午11:13 寫道：

> On 2012-11-14 15:40, Peter Cheung wrote:
>> Hi   Cannot use gdb protocol, because it is slow.
> 
> For any practical purpose I came across so far while debugging guest
> kernels, that is not true when running against QEMU. Sure, if you want
> to dump gigabytes of RAM this way, it will be a bottleneck. But when do
> you have to do this while interactively debugging? Printing the content
> will still take longer than transmitting it.
> 
>> Also, the original gdb stub can dump out GDT/IDT/CR0 directly.
> 
> That is true, but it should be addressed in gdb. Folks there are aware
> of the issue and will happily discuss extension proposals and likely
> also take the necessary patches. It will be trivial to adapt QEMU to
> such an extension afterward.
> 
> Also, this is a temporary, just too long pending issue for x86. I'm not
> aware of such limitations for other architectures.
> 
> And there is actually workaround for the meantime: issue "monitor info
> registers" in the gdb session to obtain also those registers. "monitor
> cpu N" will allow you to switch between CPUs. It's not nice but saved my
> days a few times already.
> 
> Jan
> 
>> 
>> Thanksfrom Peter
>> 
>>> Date: Wed, 14 Nov 2012 10:54:02 +0000
>>> From: peter.maydell@linaro.org
>>> To: mcheung63@hotmail.com
>>> CC: qemu-devel@nongnu.org
>>> Subject: Re: [Qemu-devel] Adding another debug protocol
>>> 
>>> On 14 November 2012 10:45, Peter Cheung <mcheung63@hotmail.com> wrote:
>>>> Dear All
>>>>    I am going to add another debugger server into QEMU, so i need to
>>>> 1) create another socket server, similar than gdbserver, to receive the
>>>> command from debugger
>>>> 2) add another option, such as "--start-debugger-server" to start the socket
>>>> server.
>>>> 
>>>> After I work out the whole thing, how can i ask for the qemu maintainer to
>>>> accept my code? I believe i should write a proposal first.
>>> 
>>> Probably worth including a summary of why your second debug protocol
>>> couldn't be implemented as a translation layer between gdbserver
>>> protocol and whatever it is you need.
>>> 
>>> -- PMM
> 
> -- 
> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> Corporate Competence Center Embedded Linux
> 

Re: [Qemu-devel] Adding another debug protocol

[Jan Kiszka]

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

Re: [Qemu-devel] Adding another debug protocol

[Peter Cheung]

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

> Date: Wed, 14 Nov 2012 17:43:12 +0100
> From: jan.kiszka@siemens.com
> To: mcheung63@hotmail.com
> CC: peter.maydell@linaro.org; qemu-devel@nongnu.org
> 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.
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.
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.
thanks

 		 	   		  

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

Re: [Qemu-devel] Adding another debug protocol

[Jan Kiszka]

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

On 2012-11-15 02:58, Peter Cheung wrote:
>> Date: Wed, 14 Nov 2012 17:43:12 +0100
>> From: jan.kiszka@siemens.com
>> To: mcheung63@hotmail.com
>> CC: peter.maydell@linaro.org; qemu-devel@nongnu.org
>> 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


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

Re: [Qemu-devel] Adding another debug protocol

[Peter Cheung]

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

Hi All   I still prefer to create my debug server, i think this would be more flexible. I will provide a patch from my website, although the changes can't be commit to qemu source, but people still able to patch it by themselves. thanks

Thanksfrom Peter

> Date: Thu, 15 Nov 2012 09:02:39 +0100
> From: jan.kiszka@web.de
> To: mcheung63@hotmail.com
> CC: peter.maydell@linaro.org; qemu-devel@nongnu.org
> Subject: Re: Adding another debug protocol
> 
> On 2012-11-15 02:58, Peter Cheung wrote:
> >> Date: Wed, 14 Nov 2012 17:43:12 +0100
> >> From: jan.kiszka@siemens.com
> >> To: mcheung63@hotmail.com
> >> CC: peter.maydell@linaro.org; qemu-devel@nongnu.org
> >> 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
> 
 		 	   		  

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