From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JzZGv-0000Oa-Ft for qemu-devel@nongnu.org; Fri, 23 May 2008 11:33:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JzZGu-0000O5-R9 for qemu-devel@nongnu.org; Fri, 23 May 2008 11:33:33 -0400 Received: from [199.232.76.173] (port=42041 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JzZGu-0000O2-MM for qemu-devel@nongnu.org; Fri, 23 May 2008 11:33:32 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:34358) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JzZGu-00072L-4k for qemu-devel@nongnu.org; Fri, 23 May 2008 11:33:32 -0400 Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate02.web.de (Postfix) with ESMTP id 907F8DE0DAF6 for ; Fri, 23 May 2008 17:33:31 +0200 (CEST) Received: from [88.64.30.47] (helo=[192.168.1.198]) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1JzZGt-0004Qz-00 for qemu-devel@nongnu.org; Fri, 23 May 2008 17:33:31 +0200 Message-ID: <4836E3B7.1080601@web.de> Date: Fri, 23 May 2008 17:33:11 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1210860693-22245-1-git-send-email-jason.wessel@windriver.com> <1210860693-22245-2-git-send-email-jason.wessel@windriver.com> <1210860693-22245-3-git-send-email-jason.wessel@windriver.com> <20080515221716.GC27300@edgar.se.axis.com> <483180AD.40704@windriver.com> <291f35090805210558l3eae915ch5937c311f37f91bd@mail.gmail.com> <483455E3.1080706@windriver.com> <48357404.2040608@web.de> <483578EB.1070403@windriver.com> <48357AC2.5010302@web.de> <4835A59E.5040708@windriver.com> In-Reply-To: <4835A59E.5040708@windriver.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4673BDC733F698C41B9ECA9F" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH 2/5] gdbstub: gdb pass-through qemu monitor support Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4673BDC733F698C41B9ECA9F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jason Wessel wrote: > Jan Kiszka wrote: >> Jason Wessel wrote: >> =20 >>> Jan Kiszka wrote: >>> =20 >>>> Jason Wessel wrote: >>>> =20 >>>> =20 >>>>> Maxim Gorbachyov wrote: >>>>> =20 >>>>> =20 >>>>>> On Mon, May 19, 2008 at 5:29 PM, Jason Wessel >>>>>> wrote: >>>>>> >>>>>> [cut] >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>>> Seems reasonable too, see newly attached patch. >>>>>>> >>>>>>> Obviously you need the new monitor patch applied prior to this on= e. >>>>>>> This patch was updated against the prior patch. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>> It was noticed [by Jan Kiszka and me] that the output on the monit= or >>>>>> console goes both to the local as well as the remote one - but onl= y if >>>>>> you issue a command via gdb. When you type in the command locally = (ie. >>>>>> on the qemu side), that output is not forwarded to the gdb fronten= d. >>>>>> Is this behavior desired? >>>>>> >>>>>> >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>> That was certainly the intended behavior when I created the patch. = >>>>> There is no reason to feed the monitor output up to the debugger th= at >>>>> may or may not be attached. >>>>> =20 >>>>> =20 >>>> That's not what we were confused by. >>>> >>>> =20 >>>> =20 >>>>> The behavior could get altered to check if >>>>> the debugger is in the "continue" state and then send the informati= on >>>>> from the monitor, but it seemed of little value to do so. >>>>> =20 >>>>> =20 >>>> Rather the contrary: What is the point of mirroring the output you s= ee >>>> in gdb to the local monitor console? >>>> >>>> =20 >>>> =20 >>> That happens to have little to do with the gdb implementation. It is= a >>> function of the monitor mux. The monitor mux always writes out to al= l >>> the output channels automatically. In the case of gdb sending input= >>> for which you only want to receive the response it would be plausible= to >>> add a "focus" parameter to the monitor mux code to indicate which >>> "channel" to send the output to. >>> >>> The monitor mux could also be changed to simply shift the output focu= s >>> to the most recent place it received an input, and if the focus was -= 1 >>> to start it would broadcast every where, the way it does today. It i= s a >>> trivial enough change, if this is what you are looking for. >>> =20 >> Yep, would be nice. >> >> Jan >> >> =20 >=20 > Jan, >=20 > See the newly attached patches which address the problem you raised. I= > removed the monitor broadcast code entirely and replaced it with the > "mon_active" because it is not likely that there will ever be two > exactly concurrent users of the qemu monitor. You either use it from > one place or another at a time. >=20 > Apply in order: > gdb_single_step_monitor_cmd.patch > gdb_monitor_plus_qemu_monitor.patch Thanks, work nicely here! Jan --------------enig4673BDC733F698C41B9ECA9F 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.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFINuPFniDOoMHTA+kRAgSxAJ9zYvqpAVljKQooat66uiKfmwVbSwCfUF5I qWjiTxheExRPNbWryq97p6A= =eY6E -----END PGP SIGNATURE----- --------------enig4673BDC733F698C41B9ECA9F--