From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNjhb-0000tr-Qv for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:05:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNjhZ-0000tf-6t for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:05:14 -0500 Received: from [199.232.76.173] (port=53653 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNjhZ-0000tc-0r for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:05:13 -0500 Received: from mx20.gnu.org ([199.232.41.8]:63486) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNjhY-0001xZ-Am for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:05:12 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNjhW-0000jx-VI for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:05:11 -0500 Message-ID: <49703FAD.1060107@web.de> Date: Fri, 16 Jan 2009 09:05:01 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RESEND][PATCH] gdbstub: Add vCont support References: <496DFA33.2020606@siemens.com> <496F9D75.4020802@codemonkey.ws> <496FAA5D.3000403@web.de> <200901160015.44729.paul@codesourcery.com> In-Reply-To: <200901160015.44729.paul@codesourcery.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5C7BF1562348716360F7EC8C" 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: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5C7BF1562348716360F7EC8C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul Brook wrote: >> a) Modeling cpus as processes buys us nothing compared to threads giv= en >> the fact that we cannot provide a stable memory mapping to the gdb= >> frontend anyway. (*) >=20 > I disagree. The process model fits perfectly. The whole point is that e= ach CPU=20 > has its own virtual address space. Separate address spaces is the funda= mental=20 > difference between a process and a thread. >=20 > If you have a multicore system where several cores share a MMU[1] then = > modelling these as threads probably make sense. >=20 > Don't confuse this with OS awareness in GDB (i.e. implementing a usersp= ace=20 > debug environment via a bare metal kernel level debug interface). That'= s a=20 > completely separate issue. You snipped away my argument under (*): > (*) Process abstraction is, if used at all, guest business. At best we > could try to invent (likely OS-specific) heuristics to identify > identical mappings and call them processes. I don't see a reasonable > benefit compared to the expected effort and unreliability. You cannot simply assign some CPU n to a virtual process n because the mapping you see on that CPU at some point in time may next pop up on some other CPU - and vice versa. You start to make gdb believe it sees consistent processes while you have no clue at all about the scheduling of your guest. So what do you gain? I can tell you what you loose: If gdb starts to think that there are n separate processes, you will have to set separate breakpoints as well. Bad. And if some breakpoint assigned to process n suddenly hits you on process (CPU) m, only chaos is the result. E.g. kvm would re-inject it as guest-originated. Even worse. >=20 >> b) The model is already part of mainline qemu. This patch is just >> about adding even more usefulness to it. >=20 > I have no problems with ripping out the bogus "thread" support once (or= even=20 > before) proper process support is implemented. Likewise I've no proble= m=20 > requiring a recent GDB if you want to do multicore debugging. There was zero practical need for this so far. But maybe you can describe a _concrete_ debugging use case and the related steps in gdb - based on a potential process interface. I'm surely willing to learn about it if there is really such a great practical improvement feasible. What will be the user's benefit? Jan --------------enig5C7BF1562348716360F7EC8C 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 iEYEARECAAYFAklwP7IACgkQniDOoMHTA+liTACeL3RjcUU9xIT2gtqERbgl2sAx /dEAniU/14RG43LE0/cIiV2XaOt0Gwfm =9rV+ -----END PGP SIGNATURE----- --------------enig5C7BF1562348716360F7EC8C--