summaryrefslogtreecommitdiff
path: root/configure
diff options
context:
space:
mode:
authorNathan Froyd <froydnj@codesourcery.com>2009-06-03 11:33:08 -0700
committerPaul Brook <paul@codesourcery.com>2009-06-04 10:04:49 +0100
commit1e9fa730163c2a445014ff8324b169cd82a50df1 (patch)
tree5d149df819dc4213b77c82ae7eb6249010d68ac3 /configure
parent4548eaea135af6c0570dc220813dab8a017c9ea2 (diff)
downloadqemu-1e9fa730163c2a445014ff8324b169cd82a50df1.tar.gz
qemu-1e9fa730163c2a445014ff8324b169cd82a50df1.tar.bz2
qemu-1e9fa730163c2a445014ff8324b169cd82a50df1.zip
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>
Diffstat (limited to 'configure')
0 files changed, 0 insertions, 0 deletions