fix gdbstub support for multiple threads in usermode, v3
authorNathan Froyd <froydnj@codesourcery.com>
Wed, 3 Jun 2009 18:33:08 +0000 (11:33 -0700)
committerPaul Brook <paul@codesourcery.com>
Thu, 4 Jun 2009 09:04:49 +0000 (10:04 +0100)
commit1e9fa730163c2a445014ff8324b169cd82a50df1
tree5d149df819dc4213b77c82ae7eb6249010d68ac3
parent4548eaea135af6c0570dc220813dab8a017c9ea2
fix gdbstub support for multiple threads in usermode, v3

When debugging multi-threaded programs, QEMU's gdb stub would report the
correct number of threads (the qfThreadInfo and qsThreadInfo packets).
However, the stub was unable to actually switch between threads (the T
packet), since it would report every thread except the first as being
dead.  Furthermore, the stub relied upon cpu_index as a reliable means
of assigning IDs to the threads.  This was a bad idea; if you have this
sequence of events:

initial thread created
new thread #1
new thread #2
thread #1 exits
new thread #3

thread #3 will have the same cpu_index as thread #1, which would confuse
GDB.  (This problem is partly due to the remote protocol not having a
good way to send thread creation/destruction events.)

We fix this by using the host thread ID for the identifier passed to GDB
when debugging a multi-threaded userspace program.  The thread ID might
wrap, but the same sort of problems with wrapping thread IDs would come
up with debugging programs natively, so this doesn't represent a
problem.

Signed-off-by: Nathan Froyd <froydnj@codesourcery.com>
cpu-defs.h
exec.c
gdbstub.c
linux-user/syscall.c