qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [RESEND][PATCH] gdbstub: Add vCont support


From: Jamie Lokier
Subject: Re: [Qemu-devel] Re: [RESEND][PATCH] gdbstub: Add vCont support
Date: Sat, 17 Jan 2009 10:03:51 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]