From: Jan Kiszka <jan.kiszka@web.de>
To: Peter Cheung <mcheung63@hotmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Adding another debug protocol
Date: Thu, 15 Nov 2012 09:02:39 +0100 [thread overview]
Message-ID: <50A4A19F.7080808@web.de> (raw)
In-Reply-To: <BAY002-W2057ED04983B3C2C2DD2A7EB5520@phx.gbl>
[-- 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 --]
next prev parent reply other threads:[~2012-11-15 8:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-14 10:45 [Qemu-devel] Adding another debug protocol Peter Cheung
2012-11-14 10:54 ` Peter Maydell
2012-11-14 14:40 ` Peter Cheung
2012-11-14 15:13 ` Jan Kiszka
2012-11-14 16:28 ` Peter Cheung
2012-11-14 16:43 ` Jan Kiszka
2012-11-15 1:58 ` Peter Cheung
2012-11-15 8:02 ` Jan Kiszka [this message]
2012-11-15 8:44 ` Peter Cheung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50A4A19F.7080808@web.de \
--to=jan.kiszka@web.de \
--cc=mcheung63@hotmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).