|
From: | Peter Cheung |
Subject: | Re: [Qemu-devel] Adding another debug protocol |
Date: | Thu, 15 Nov 2012 16:44:25 +0800 |
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 Thanks from Peter > Date: Thu, 15 Nov 2012 09:02:39 +0100 > From: address@hidden > To: address@hidden > CC: address@hidden; address@hidden > 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: 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 > |
[Prev in Thread] | Current Thread | [Next in Thread] |