From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LE9nz-00040S-NX for qemu-devel@nongnu.org; Sat, 20 Dec 2008 16:56:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LE9ny-00040G-8n for qemu-devel@nongnu.org; Sat, 20 Dec 2008 16:56:15 -0500 Received: from [199.232.76.173] (port=57847 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LE9ny-00040D-5T for qemu-devel@nongnu.org; Sat, 20 Dec 2008 16:56:14 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:47907) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LE9nx-00089A-Ir for qemu-devel@nongnu.org; Sat, 20 Dec 2008 16:56:13 -0500 Message-ID: <494D69BF.6010008@web.de> Date: Sat, 20 Dec 2008 22:55:11 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: gdbstub: packet reply is too long References: <1229776952.22890.2.camel@ws-aschultz> <200812202103.19216.paul@codesourcery.com> <494D620A.8020102@web.de> <200812202134.01169.paul@codesourcery.com> In-Reply-To: <200812202134.01169.paul@codesourcery.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1FBC97A046AEE185D2262467" Sender: jan.kiszka@web.de Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Andreas Schultz , qemu-devel@nongnu.org, kvm@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1FBC97A046AEE185D2262467 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul Brook wrote: >>>> From a higher perspective, it is surely not the cleanest approach. B= ut >>>> it still appears to be the only one which helps us working around th= is >>>> 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? >=20 > Because, as I've said several times before, the "automatic switching" i= s=20 > wrong. It may happen to work in your very limited circumstances, but th= ere=20 > are many fairly common circumstances (e.g. stepping between a 64-bit ke= rnel=20 > and a 32-bit userspace) where it's just plain broken. I object strongly= to=20 > a "fix" that prevents a proper gdb from working. Well, I'm using gdb over qemu and kvm in precisely that hybrid scenarios, but also in normal ones. Heavily. And I'm only able to do this because of the workaround. But I'm willing to learn about scenarios where it causes /regressions/. >=20 >> 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 >=20 > Really? I'm pretty sure other architectures already manage it. What other archs are comparably weird like x86? Please have a look at the gdb code that I pointed out and explain to me how it can be fixed so that the next gdb version will be fine again with current qemu. I will happily do the patching then. Though, it would still leave us with broken setups until that release is spread sufficient= ly. Jan --------------enig1FBC97A046AEE185D2262467 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAklNacMACgkQniDOoMHTA+lupwCcCyw2a+gUNLbolc/qDswfR3oC 6dEAniuYWIL0RnwqydA2OIQ+IjZDPR5H =PuGU -----END PGP SIGNATURE----- --------------enig1FBC97A046AEE185D2262467--