From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LE9SZ-0005Qj-AZ for qemu-devel@nongnu.org; Sat, 20 Dec 2008 16:34:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LE9SW-0005Ny-RR for qemu-devel@nongnu.org; Sat, 20 Dec 2008 16:34:06 -0500 Received: from [199.232.76.173] (port=57468 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LE9SW-0005Nd-LD for qemu-devel@nongnu.org; Sat, 20 Dec 2008 16:34:04 -0500 Received: from mx20.gnu.org ([199.232.41.8]:51281) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LE9SW-0005EW-Dc for qemu-devel@nongnu.org; Sat, 20 Dec 2008 16:34:04 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LE9SV-0003Xi-Hw for qemu-devel@nongnu.org; Sat, 20 Dec 2008 16:34:03 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Re: gdbstub: packet reply is too long Date: Sat, 20 Dec 2008 21:34:00 +0000 References: <1229776952.22890.2.camel@ws-aschultz> <200812202103.19216.paul@codesourcery.com> <494D620A.8020102@web.de> In-Reply-To: <494D620A.8020102@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812202134.01169.paul@codesourcery.com> 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 Cc: Andreas Schultz , Jan Kiszka , kvm@vger.kernel.org > >> From a higher perspective, it is surely not the cleanest approach. But > >> it still appears to be the only one which helps us working around this > >> gdb shortcoming. > > > > Actually it isn't. You could add an explicit switch. > > And what would this buy us? I would have to go from your gdb terminal to > qemu, probably the monitor, just to switch manually what now happens > automatically. I don't see the case where you wouldn't want to switch > when you try to debug 16 or 32 bit code, so what would be the gain? Or > do you want some switch to disable this automatic register format > switching? Because, as I've said several times before, the "automatic switching" is wrong. It may happen to work in your very limited circumstances, but there are many fairly common circumstances (e.g. stepping between a 64-bit kernel and a 32-bit userspace) where it's just plain broken. I object strongly to a "fix" that prevents a proper gdb from working. > There are internal issues in gdb (hard coupling of current and target > arch) that will not allow this to be fixed in the near future Really? I'm pretty sure other architectures already manage it. Paul