From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MR3jQ-0000Uy-CA for qemu-devel@nongnu.org; Wed, 15 Jul 2009 08:37:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MR3jL-0000Ru-34 for qemu-devel@nongnu.org; Wed, 15 Jul 2009 08:37:07 -0400 Received: from [199.232.76.173] (port=40096 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MR3jK-0000Rh-T8 for qemu-devel@nongnu.org; Wed, 15 Jul 2009 08:37:02 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:43995) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MR3jK-0007OB-7w for qemu-devel@nongnu.org; Wed, 15 Jul 2009 08:37:02 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n6FCeEle021704 for ; Wed, 15 Jul 2009 08:40:14 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n6FCapuF216064 for ; Wed, 15 Jul 2009 08:36:51 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6FCaoxm017393 for ; Wed, 15 Jul 2009 08:36:50 -0400 Message-ID: <4A5DCD60.8030209@us.ibm.com> Date: Wed, 15 Jul 2009 07:36:48 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] monitor: Add port write command References: <4A5C3FBB.10306@siemens.com> <200907142030.27019.paul@codesourcery.com> <20090715073451.GF28046@redhat.com> <200907151114.21482.paul@codesourcery.com> In-Reply-To: <200907151114.21482.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Jan Kiszka , qemu-devel@nongnu.org, Gleb Natapov Paul Brook wrote: > If you don't have qemu sources than I really don't care. By definition you're > not going to be able to do anything useful even if you do figure out what the > problem is. Note that there's no requirement that you run gdb on the target > itself. Remote debug (e.g. via gdbserver on linux) is a well established > technique. > > Likewise for debugging stripped production binaries, my answer is "don't do > that". There are very rare cases where a bug goes away on a debug build, but > in those cases any instrumentation you add is also liable to make the bug go > away. > If we had an info device, it would fall into the same category as info cpu or info registers. It duplicates the functionality of the gdbstub but it provides a convenience interface for those who don't have gdb connected. Since there isn't really an obvious way to expose the device state via gdb without using Rcmd and a new monitor command, the whole debate seems academic :-) -- Regards, Anthony Liguori