From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LO824-0001A5-IV for qemu-devel@nongnu.org; Sat, 17 Jan 2009 05:04:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LO822-00017z-PS for qemu-devel@nongnu.org; Sat, 17 Jan 2009 05:03:59 -0500 Received: from [199.232.76.173] (port=47519 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LO822-00017o-40 for qemu-devel@nongnu.org; Sat, 17 Jan 2009 05:03:58 -0500 Received: from mail2.shareable.org ([80.68.89.115]:49116) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LO821-00038U-6i for qemu-devel@nongnu.org; Sat, 17 Jan 2009 05:03:57 -0500 Date: Sat, 17 Jan 2009 10:03:51 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [RESEND][PATCH] gdbstub: Add vCont support Message-ID: <20090117100350.GB20389@shareable.org> References: <496DFA33.2020606@siemens.com> <496F9D75.4020802@codemonkey.ws> <496FAA5D.3000403@web.de> <200901160015.44729.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901160015.44729.paul@codesourcery.com> 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 Cc: Jan Kiszka Paul Brook wrote: > > a) Modeling cpus as processes buys us nothing compared to threads given > > the fact that we cannot provide a stable memory mapping to the gdb > > frontend anyway. (*) > > I disagree. The process model fits perfectly. The whole point is > that each CPU has its own virtual address space. Separate address > spaces is the fundamental difference between a process and a thread. That isn't so fundamental. Distinct CPUs in an OS like Linux have most of the kernel address space shared between them - except when in special modes like 4G. But some of the kernel address space is per-CPU. Threads do not necessarily share the whole virtual address space: sometimes thread-specific storage is mapped into the same address in each thread. In Windows processes, historically it's been possible to have a mixture of process-specific mapped segments and system-wide shared segments, which looks more like threads. Of course there's the no-MMU architectures too. So the distinction which really matters is, surely, with which model does GDB behave most usefully with multiple CPUs having their own MMUs? Does GDB _assume_ all threads have exactly the same address space, or does GDB allow for threads which have some thread-local mappings, and therefore always use the correct thread when examining memory etc.? -- Jamie