Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org,  luisgpm@linux.vnet.ibm.com
Subject: Re: (maybe) Async mode failures on PPC
Date: Tue, 15 Jul 2008 16:34:00 -0000	[thread overview]
Message-ID: <200807151734.30838.pedro@codesourcery.com> (raw)
In-Reply-To: <1216133200.7260.4.camel@gargoyle>

Hi Luis,

Thanks for taking care of this.

> 2008-07-15  Luis Machado  <luisgpm@br.ibm.com>
>
> 	* infrun.c (handle_inferior_event): reinit_frame_cache before
> 	handling events on threads.

As I noted on IRC, this is a bit incomplete, but I know you're already
handling it.  :-)

On Tuesday 15 July 2008 15:46:40, Luis Machado wrote:
> On Mon, 2008-07-14 at 14:06 -0300, Luis Machado wrote:
> Here is a patch i discussed with Pedro to fix this regression. Tested
> and nothing showed up in the testsuite.

For everyone else not following the discussion on IRC:

The main issue was the insert_breakpoints call being done
before the stopped thread being tagged as stopped, as Andreas
also noticed.  Inside insert_breakpoints, when updating
watchpoints, there are calls into frame routines, which
bail out if the thread is considered to be running.  It isn't
at this point, but we were only tagging it as stopped a bit
afterwards.

handle_inferior_event()
{
...
  switch (infwait_state)
    {
...
    case infwait_nonstep_watch_state:
      if (debug_infrun)
        fprintf_unfiltered (gdb_stdlog,
			    "infrun: infwait_nonstep_watch_state\n");
      insert_breakpoints ();
...
      break;
...

    }
...

  reinit_frame_cache ();

  /* If it's a new process, add it to the thread database */

  ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
			   && !ptid_equal (ecs->ptid, minus_one_ptid)
			   && !in_thread_list (ecs->ptid));

  if (ecs->ws.kind != TARGET_WAITKIND_EXITED
      && ecs->ws.kind != TARGET_WAITKIND_SIGNALLED && ecs->new_thread_event)
    add_thread (ecs->ptid);

  if (ecs->ws.kind != TARGET_WAITKIND_IGNORE)
    {
      /* Mark the non-executing threads accordingly.  */
      if (!non_stop
 	  || ecs->ws.kind == TARGET_WAITKIND_EXITED
 	  || ecs->ws.kind == TARGET_WAITKIND_SIGNALLED)
 	set_executing (pid_to_ptid (-1), 0);
      else
 	set_executing (ecs->ptid, 0);
    }
...




> Index: gdb/infrun.c
> ===================================================================
> --- gdb.orig/infrun.c	2008-07-15 09:36:19.000000000 -0500
> +++ gdb/infrun.c	2008-07-15 09:37:20.000000000 -0500
> @@ -1828,6 +1828,29 @@
>
>    adjust_pc_after_break (ecs);
>
> +  reinit_frame_cache ();

As seen above, this was being done only after the insert_breakpoints call.
Inserting breakpoints ends up updating the watchpoints, which
triggers calls into frame handling (evaluating if the frame is
in scope, temporalily changing the selected frame, etc.).

There's a registers_changed call just before resuming and switching
to infwait_nonstep_watch_state (which calls reinit_frame_cache),
and we tell the target to step only one thread, so there should be no 
practical problem in leaving the call where it was, but, might
as well move up this call too while we're at it, in case something
else changes in the future, and uncovers this issue.

> +
> +  /* If it's a new process, add it to the thread database */
> +
> +  ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
> +			   && !ptid_equal (ecs->ptid, minus_one_ptid)
> +			   && !in_thread_list (ecs->ptid));
> +
> +  if (ecs->ws.kind != TARGET_WAITKIND_EXITED
> +      && ecs->ws.kind != TARGET_WAITKIND_SIGNALLED &&
> ecs->new_thread_event) +    add_thread (ecs->ptid);

This moves up along, so any new thread that ends up being added by
this is also tagged as stopped.  It's the default thread state, when
one adds a new thread, but we shouldn't rely on that.

> +
> +  if (ecs->ws.kind != TARGET_WAITKIND_IGNORE)
> +    {
> +      /* Mark the non-executing threads accordingly.  */
> +      if (!non_stop
> + 	  || ecs->ws.kind == TARGET_WAITKIND_EXITED
> + 	  || ecs->ws.kind == TARGET_WAITKIND_SIGNALLED)
> + 	set_executing (pid_to_ptid (-1), 0);
> +      else
> + 	set_executing (ecs->ptid, 0);
> +    }
> +

This moves up, because doing this later is what was creating
the problem in the first place, due to insert_breakpoints
ending up calling get_current_frame.

-- 
Pedro Alves


  reply	other threads:[~2008-07-15 16:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-14 15:45 Luis Machado
2008-07-14 16:32 ` Luis Machado
2008-07-14 16:58   ` Pedro Alves
2008-07-14 17:07     ` Luis Machado
2008-07-15 14:47       ` Luis Machado
2008-07-15 16:34         ` Pedro Alves [this message]
2008-07-15 16:40           ` Daniel Jacobowitz
2008-07-15 16:42             ` Pedro Alves
2008-07-15 16:45         ` Luis Machado
2008-07-15 16:49           ` Daniel Jacobowitz
2008-07-15 17:30             ` Luis Machado
2008-07-14 21:37     ` Andreas Schwab

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=200807151734.30838.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb@sourceware.org \
    --cc=luisgpm@linux.vnet.ibm.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