[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 18:53:44 +0200
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:126.96.36.199) Gecko/20080226 SUSE/188.8.131.52-1.1 Thunderbird/184.108.40.206 Mnenhy/0.7.5.666
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)
>>> 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.
Description: OpenPGP digital signature