[Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode

[Nathan Froyd <froydnj@codesourcery.com>]

On Tue, May 12, 2009 at 10:53:22PM +0200, Jan Kiszka wrote:
> Nathan Froyd wrote:
> > We fix this by adding a stable gdbstub_index field for each CPU; the
> > index is incremented for every CPU (thread) created.  We ignore
> > wraparound issues for now.  Once we have this field, the stub needs to
> > use this field instead of cpu_index for communicating with GDB.
> > [...]
> > @@ -554,6 +556,7 @@ void cpu_exec_init(CPUState *env)
> >          cpu_index++;
> >      }
> >      env->cpu_index = cpu_index;
> > +    env->gdbstub_index = ++next_gdbstub_index;
> 
> While this is simple and sufficient for most cases, making
> next_gdbstub_index robust against collisions due to overflow is not much
> more complicated - so why not do this right from the beginning?

We could just make it a 64-bit field. :)

The best way I can think of to do this is to maintain a
separately-chained list of CPUStates (through a new field similar to
next_cpu) ordered by gdbstub_index.  Grabbing a new gdbstub_index then
walks through the list, looking for "holes" between adjacent entries in
the list.  A new gdbstub_index is then picked if we find a hole; we die
if we can't find a hole.

Is this what you had in mind, or am I not being clever enough?

> I don't think we need these #ifdefs here. You assign continuously
> increasing IDs also to system-mode CPUs, so we can handle them
> identically (we have to anyway once cpu hotplugging hits upstream).

Will fix, thanks.

> Hmm, I bet you now have some use for my good-old vCont patch (=>continue
> single-stepping on different CPU / in different thread). Will repost soon.

Yes, I think that would be useful.

-Nathan