Nathan Froyd wrote:
> On Tue, Jun 02, 2009 at 10:14:22PM +0100, Paul Brook wrote:
>>>> Really? Why doesn't GDB get confused on real machines when the PID wraps?
>>>> Is the real bug that we're missing some sort of thread
>>>> creation/destruction event reporting?
>>> Hm, this is a good point.  I think the bug is that:
>>> ...
>>> I'm also not sure what to do differently that doesn't involve making
>>> QEMU remember what happened to all the threads it's seen until GDB asks
>>> about them.  Ideas?
>> Ok, from Daniel's response it sounds like this bit of gdb is broken.
>>
>> Could we use the real TID? Seems silly to invent a new value when the host has 
>> already found one for us...
> 
> That would work for threaded usermode emulation.  But for multiple-cpu
> system-mode emulation, the CPUs are unlikely to have unique TID values
> (e.g. r2 on powerpc or what have you).  And if you're going to support
> hotplugging someday, you're going to have support generation of unique
> IDs somewhere along the way.  Using the same code for usermode and
> system mode seems like the better, more robust/future-proof option.

For system-mode emulation, this is not that problematic. The threaded
model assumes that all CPUs use the same memory mapping (for the code of
interest at least) and are programmed with the same set of
break/watchpoints. Pulling one and reinserting it will not require gdb
to handle the newly plugged one differently within this model.

Once we have a true multicore model for gdb and proper protocol
extensions to handle more complex use cases, I bet we will also have a
CPU hotplug event channel for gdb.

Jan