qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Nathan Froyd <froydnj@codesourcery.com>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2
Date: Tue, 2 Jun 2009 13:54:40 -0700	[thread overview]
Message-ID: <20090602205440.GB21107@codesourcery.com> (raw)
In-Reply-To: <200906022108.15384.paul@codesourcery.com>

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

  parent reply	other threads:[~2009-06-02 20:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02 19:53 [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2 Nathan Froyd
2009-06-02 20:08 ` Paul Brook
2009-06-02 20:46   ` Daniel Jacobowitz
2009-06-02 20:54   ` Nathan Froyd [this message]
2009-06-02 21:14     ` Paul Brook
2009-06-02 21:48       ` Nathan Froyd
2009-06-02 21:56         ` Paul Brook
2009-06-16 19:11           ` [Qemu-devel] " Antti P Miettinen
2009-06-16 19:25             ` Paul Brook
2009-06-16 20:02               ` Antti P Miettinen
2009-06-17 16:39               ` Jan Kiszka
2009-06-02 22:44         ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090602205440.GB21107@codesourcery.com \
    --to=froydnj@codesourcery.com \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).