Nathan Froyd wrote:
> 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. :)

Well... kind of pragmatic.

> 
> 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.

Why creating a new list? Just generate a new index and then walk through
all so far registered CPUStates until no collision is found.

> 
> 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.

On my todo list. I practically just need to include your patch in my queue.

Jan