qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]