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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]

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.
> 
> If you have a multicore system where several cores share a MMU[1] then 
> modelling these as threads probably make sense.
> 
> Don't confuse this with OS awareness in GDB (i.e. implementing a userspace 
> debug environment via a bare metal kernel level debug interface). That's a 
> 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.

> 
>>  b) The model is already part of mainline qemu. This patch is just
>>     about adding even more usefulness to it.
> 
> I have no problems with ripping out the bogus "thread" support once (or even 
> before) proper process support is implemented.  Likewise I've no problem 
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]