From: Keith Seitz <keiths@redhat.com>
To: Michael Snyder <msnyder@vmware.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>,
swagiaal@redhat.com, oguzkayral@gmail.com
Subject: Re: New testsuite errors with gdbserver (remote)
Date: Thu, 17 Feb 2011 20:48:00 -0000 [thread overview]
Message-ID: <4D5D8974.5030205@redhat.com> (raw)
In-Reply-To: <4D5D6D83.8030302@vmware.com>
On 02/17/2011 10:48 AM, Michael Snyder wrote:
> Somewhat to my surprise, these new failures narrow down to this change:
I've given this a peek, and here's what I've found out...
When the exit notification is sent, and python picks it up, it is
setting up the python environment (architecture and language). The
python exit callback does this by calling get_current_arch.
The problem is that (long before this) wait_for_inferior sets the
inferior with TID = 0. It is this inferior object that is then passed
around for the event notification. Alas, unlike natives, where the
inferior is popped, the inferior is still around.
As a result, target_has_stack goes to check the thread status and cannot
find the appropriate thread (since the one in the list hasn't been
cleared). This leads to the internal error you're seeing.
I'm not sure how valid it is to call get_current_arch from an exit
event. Maybe it is. Maybe it isn't. Someone who knows a lot more about
this is going to have to investigate this or guide me.
Nonetheless, if you pass target_gdbarch instead to ensure_python_env in
python_inferior_exit (in python/py_inferior.c), things will behave much
better. Once again, I don't know if this is strictly correct, but it
should at least get you going with gdbserver again.
I hope this leads someone to a better solution.
Keith
Index: python/py-inferior.c
===================================================================
RCS file: /cvs/src/src/gdb/python/py-inferior.c,v
retrieving revision 1.5
diff -u -p -r1.5 py-inferior.c
--- python/py-inferior.c 4 Feb 2011 21:54:16 -0000 1.5
+++ python/py-inferior.c 17 Feb 2011 20:46:08 -0000
@@ -116,7 +116,7 @@ python_inferior_exit (struct inferior *i
ptid_t ptidp;
struct target_waitstatus status;
- cleanup = ensure_python_env (get_current_arch (), current_language);
+ cleanup = ensure_python_env (target_gdbarch, current_language);
get_last_target_status (&ptidp, &status);
next prev parent reply other threads:[~2011-02-17 20:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-17 0:55 Michael Snyder
2011-02-17 1:09 ` Michael Snyder
2011-02-17 2:08 ` Michael Snyder
2011-02-17 18:48 ` Michael Snyder
2011-02-17 20:48 ` Keith Seitz [this message]
2011-02-18 16:48 ` [RFA] Fix for " Pierre Muller
2011-02-18 19:30 ` New " Pedro Alves
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=4D5D8974.5030205@redhat.com \
--to=keiths@redhat.com \
--cc=gdb@sourceware.org \
--cc=msnyder@vmware.com \
--cc=oguzkayral@gmail.com \
--cc=swagiaal@redhat.com \
/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