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 23:34:09 +0100 Message-ID: <494D72E1.6020104@web.de> References: <1229776952.22890.2.camel@ws-aschultz> <200812202134.01169.paul@codesourcery.com> <494D69BF.6010008@web.de> <200812202208.34044.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig46D1126DF579B95492C48ACC" Cc: qemu-devel@nongnu.org, Andreas Schultz , kvm@vger.kernel.org To: Paul Brook Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:57093 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751472AbYLTWfM (ORCPT ); Sat, 20 Dec 2008 17:35:12 -0500 In-Reply-To: <200812202208.34044.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig46D1126DF579B95492C48ACC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul Brook wrote: >> 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 scenari= os >> where it causes /regressions/. >=20 > I find that hard to believe. Doesn't it break horribly as soon as the C= PU=20 > switches modes? It still breaks in very few corner cases, but that's (most probably) due to the fact the gdb is not yet well prepared to switch sub-architectures properly during runtime. However, it only breaks in cases that wouldn't work without the switching anyway. And you can heal them by restarting gd= b. >=20 > It's not just regressions that are important. It's the fact that once q= emu has=20 > your automatic switching hack it's impossible to make it work properly.= Interestingly, qemu used to work precisely like that before. >=20 >>>> There are internal issues in gdb (hard coupling of current and targe= t >>>> arch) that will not allow this to be fixed in the near future >>> Really? I'm pretty sure other architectures already manage it. >> What other archs are comparably weird like x86? >=20 > ARM has multiple instruction sets/cpu modes (and can mix the two within= the=20 > same process). PPC and MIPS also have something similar, though I'm not= sure=20 > how well they're supported by gdb. Do those archs also have multiple register layouts that are coupled to those different instruction sets? Do they switch the instruction sets via 'set arch'? I think x86 is (historically) special here. >=20 > I suspect you may be approaching this the wrong way. Instead of trying = to=20 > switch architectures, you probably need to teach the 64-bit debugger ho= w to=20 > debug 32-bit code. As I said, the problem in gdb is the hard coupling of the target architecture (which could perfectly stay at x86_64 for a session) and the current debugger architecture (which should be switched according to the current CPU mode). Unfortunately, this is not yet feasible with gdb, see gdbarch_update_p(). Fixing this (once understood what are all the problems preventing a fix for several years now) is one thing, keeping the workaround for current gdb in qemu is, IMHO, another. Right now we don't have a gdb fix in sight, so I'm simply voting for reintroducing the workaround. That's all. We can kill it or make it optional once the issue is solved. But we should _not_ do this _before_ it is solved, causing only pain to people who just want to use the gdbstub. Jan --------------enig46D1126DF579B95492C48ACC 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 iEYEARECAAYFAklNcuUACgkQniDOoMHTA+nwEACeNq7avAtXTq/Rhri/OA89jbsr hGUAn0ZyvrIyRlFWHIevCnzy2iicOsEh =cv2K -----END PGP SIGNATURE----- --------------enig46D1126DF579B95492C48ACC--