[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in use
From: |
Nathan Froyd |
Subject: |
Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2 |
Date: |
Tue, 2 Jun 2009 13:54:40 -0700 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Tue, Jun 02, 2009 at 09:08:14PM +0100, Paul Brook wrote:
> On Tuesday 02 June 2009, Nathan Froyd wrote:
> > 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.
>
> 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:
1) gdb_exit, called at thread exit, just blasts out a 'W' packet, when
such a packet is really only defined to be sent in response to a '?'
packet. If I understand gdb's remote.c correctly, an unrequested 'W'
packet is just going to get dropped on the floor. This behavior is
probably part of the reason GDB never sees threads die until it
queries the target again, along with...
2) The response to a '?' packet is, well, not smart:
case '?':
/* TODO: Make this return the correct value for user-mode. */
snprintf(buf, sizeof(buf), "T%02xthread:%02x;", GDB_SIGNAL_TRAP,
s->c_cpu->cpu_index+1);
put_packet(s, buf);
which is, um, inaccurate.
I'm assuming that GDB handles wrapping PIDs correctly...it's possible
that it doesn't. (For instance:
GDB has PIDs 12 and 14
GDB runs the target
PID 12 exits (I don't think a status notification gets sent here)
PID 12 gets reused by the process (no status notification here, either?)
target stops
GDB sees PID 12 still present
but I am not a Linux target GDB expert.)
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?
-Nathan
- [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2, Nathan Froyd, 2009/06/02
- Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2, Paul Brook, 2009/06/02
- Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2, Daniel Jacobowitz, 2009/06/02
- Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2,
Nathan Froyd <=
- Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2, Paul Brook, 2009/06/02
- Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2, Nathan Froyd, 2009/06/02
- Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2, Paul Brook, 2009/06/02
- [Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode, v2, Antti P Miettinen, 2009/06/16
- Re: [Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode, v2, Paul Brook, 2009/06/16
- [Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode, v2, Antti P Miettinen, 2009/06/16
- [Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode, v2, Jan Kiszka, 2009/06/17
- [Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode, v2, Jan Kiszka, 2009/06/02