From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYuPU-0006r1-7Y for qemu-devel@nongnu.org; Thu, 15 Nov 2012 03:02:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYuPR-0008Nc-59 for qemu-devel@nongnu.org; Thu, 15 Nov 2012 03:02:52 -0500 Received: from mout.web.de ([212.227.17.11]:52747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYuPQ-0008NT-RY for qemu-devel@nongnu.org; Thu, 15 Nov 2012 03:02:49 -0500 Message-ID: <50A4A19F.7080808@web.de> Date: Thu, 15 Nov 2012 09:02:39 +0100 From: Jan Kiszka MIME-Version: 1.0 References: , , , <50A3B51A.2080004@siemens.com>, , <50A3CA20.4020205@siemens.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3C2765857682CEAC0EB5760B" Subject: Re: [Qemu-devel] Adding another debug protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Cheung Cc: Peter Maydell , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C2765857682CEAC0EB5760B Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable 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 o= f >> 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 t= hink 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 e= veryone. >> >> A good general rule, not only in open source, is to at least try to fi= x >> 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 stu= b >> cannot be extended in a backward compatible way that allows your >> debugger to attach to it. That way not only your debugger (is it Windo= ws >> hosted?) could benefit from the improvements but the whole (x86) gdb w= orld. >> >> Jan >> >> PS: Please don't top-post, cite what you comment on. >> >> --=20 >> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE >> Corporate Competence Center Embedded Linux >> >=20 > 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), break= point (linear address). I guess gdb is natural to all cpu platforms, so t= hey 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 al= l my code into an .a file, and qemu dynamically load it? then i don't nee= d 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 --------------enig3C2765857682CEAC0EB5760B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCkoaUACgkQitSsb3rl5xQzCACePlcHaebMYRqYfo2VXKpNylK+ 1rMAn35cInyAU+Ss+UJVmOyfEpo8q+RC =mCpL -----END PGP SIGNATURE----- --------------enig3C2765857682CEAC0EB5760B--