[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in use
[Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode
Tue, 19 May 2009 08:06:36 -0700
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.