[Qemu-devel] Re: [5743] gdbstub: manage CPUs as threads (Jan Kiszka)

[Jan Kiszka]

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=rev&root=qemu&revision=5743
>>>> 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.  
> 
> GDB works with virtual address spaces. Each CPU has its own MMU, so as soon 
> as 
> you load a multitasking OS the chances are that these will look significantly 
> different.
> 
>> How well does GDB support 
>> debugging processes verses threads?  A cursory look seems to suggest the
>> thread debugging support is slightly better (thread events) than the
>> process debugging support.  They look very similar though.
> 
> The thread model can't describe what's actually happening. gdb multiprocess 
> 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

signature.asc
Description: OpenPGP digital signature