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
next prev 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).