From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L2Z3S-00032w-1J for qemu-devel@nongnu.org; Tue, 18 Nov 2008 17:28:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L2Z3R-00032k-9k for qemu-devel@nongnu.org; Tue, 18 Nov 2008 17:28:17 -0500 Received: from [199.232.76.173] (port=41001 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2Z3R-00032h-65 for qemu-devel@nongnu.org; Tue, 18 Nov 2008 17:28:17 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:34798) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L2Z3R-0003oG-3Z for qemu-devel@nongnu.org; Tue, 18 Nov 2008 17:28:17 -0500 Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate01.web.de (Postfix) with ESMTP id 1A778F9B070D for ; Tue, 18 Nov 2008 23:28:16 +0100 (CET) Received: from [88.64.11.56] (helo=[192.168.1.198]) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1L2Z3P-0002OR-00 for qemu-devel@nongnu.org; Tue, 18 Nov 2008 23:28:16 +0100 Message-ID: <49234152.7010103@web.de> Date: Tue, 18 Nov 2008 23:27:30 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <200811182042.59526.paul@codesourcery.com> <49232A03.3000100@codemonkey.ws> <200811182120.53504.paul@codesourcery.com> In-Reply-To: <200811182120.53504.paul@codesourcery.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig79541B4107E581CB8203E3CB" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [5743] gdbstub: manage CPUs as threads (Jan Kiszka) 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig79541B4107E581CB8203E3CB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul Brook wrote: > On Tuesday 18 November 2008, Anthony Liguori wrote: >> Paul Brook wrote: >>> On Tuesday 18 November 2008, Anthony Liguori wrote: >>>> Revision: 5743 >>>> http://svn.sv.gnu.org/viewvc/?view=3Drev&root=3Dqemu&revis= ion=3D5743 >>>> Author: aliguori >>>> Date: 2008-11-18 20:30:24 +0000 (Tue, 18 Nov 2008) >>>> >>>> Log Message: >>>> ----------- >>>> gdbstub: manage CPUs as threads (Jan Kiszka) >>> This is wrong. CPUs do not share the same address space, so should be= >>> modelled as processes, not threads. >> They share the same physical address space. =20 >=20 > GDB works with virtual address spaces. Each CPU has its own MMU, so as = soon as=20 > you load a multitasking OS the chances are that these will look signifi= cantly=20 > different. >=20 >> How well does GDB support=20 >> debugging processes verses threads? A cursory look seems to suggest t= he >> thread debugging support is slightly better (thread events) than the >> process debugging support. They look very similar though. >=20 > The thread model can't describe what's actually happening. gdb multipro= cess=20 > support definitely exists (and if it doesn't work right now it's being = > actively worked on), so we should use it. The thread model describes well what happens in many common OSes that have their interesting part mapped identically to all CPUs - take Linux as an example. For sure, you run into problems when trying to follow the OS into dynamically mapped code (e.g. userspace under Linux) - but that can already happen with _single_ CPU systems. And that is definitely not the point where I suggest qemu or kvm as your favorite debugger. That's what the guest itself can (generally) handle much better. Well, maybe gdb will further improve toward mulitprocess debugging over remote connections, and we will be able to use this instead. Right now I don't see that this is the case (please correct me by drafting an equivalent model based on mulitprocess debugging). Also, I'm a bit skeptical about the maturity of multiprocess support - given the experience I collected with multi-threading in gdb (just recently become truly usable for our scenario here). So, while CPU-to-thread mapping may not be the optimal model, it is the most usable one right now, finally enabling qemu for (many) SMP guest debugging scenarios. Believe me, it's _marvelously_ useful in this state for analyzing tricky SMP issues, specifically on x86 where you generally don't have hardware debuggers. Jan --------------enig79541B4107E581CB8203E3CB 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 iEYEARECAAYFAkkjQVIACgkQniDOoMHTA+mMSACZAaBCtGC4T/Xs+VAx0jUdG5iO vVkAoIUcssZcmqYFgcPrrJQBLtZTHL2C =VC92 -----END PGP SIGNATURE----- --------------enig79541B4107E581CB8203E3CB--