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.kis...@web.de
> To: mcheun...@hotmail.com
> CC: peter.mayd...@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.kis...@siemens.com
> >> To: mcheun...@hotmail.com
> >> CC: peter.mayd...@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
>
