Re: New testsuite errors with gdbserver (remote)

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 17 February 2011 20:47:48, Keith Seitz wrote:
> 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.

/* Return "current" architecture.  If the target is running, this is
   the architecture of the selected frame.  Otherwise, the "current"
   architecture defaults to the target architecture.

   This function should normally be called solely by the command
   interpreter routines to determine the architecture to execute a
   command in.  */
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
struct gdbarch *
get_current_arch (void)

The exited observer are called at other times, not when
preparing to execute a command in.  It is quite bogus to assume
the current architecture, frame and language have anything to do
with the inferior that has been passed is as argument to the
observer.

> @@ -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);

I can't say that I'm very familiar with most of the python layer
code, but, why does this observer need to call ensure_python_env
in the first place?  Or if it does, why doesn't it call it with
python_gdbarch like other places in py-inferior that are internal
helpers, not implementing a user command?

-- 
Pedro Alves