From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] Re: gdbstub: packet reply is too long Date: Sat, 20 Dec 2008 22:55:11 +0100 Message-ID: <494D69BF.6010008@web.de> References: <1229776952.22890.2.camel@ws-aschultz> <200812202103.19216.paul@codesourcery.com> <494D620A.8020102@web.de> <200812202134.01169.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1FBC97A046AEE185D2262467" Cc: qemu-devel@nongnu.org, Andreas Schultz , kvm@vger.kernel.org To: Paul Brook Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:47908 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751974AbYLTV4O (ORCPT ); Sat, 20 Dec 2008 16:56:14 -0500 In-Reply-To: <200812202134.01169.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: 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--