[Bug gdb/27055] Attaching to a process in non-stop mode doesn't work

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27055

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2ab76a181f3db93f051aaae66d65ff2733884d96

commit 2ab76a181f3db93f051aaae66d65ff2733884d96
Author: Pedro Alves <pedro@palves.net>
Date:   Wed Dec 23 00:34:54 2020 +0000

    Fix attaching in non-stop mode (PR gdb/27055)

    Attaching in non-stop mode currently misbehaves, like so:

     (gdb) attach 1244450
     Attaching to process 1244450
     [New LWP 1244453]
     [New LWP 1244454]
     [New LWP 1244455]
     [New LWP 1244456]
     [New LWP 1244457]
     [New LWP 1244458]
     [New LWP 1244459]
     [New LWP 1244461]
     [New LWP 1244462]
     [New LWP 1244463]
     No unwaited-for children left.

    At this point, GDB's stopped/running thread state is out of sync with
    the inferior:

    (gdb) info threads
      Id   Target Id                     Frame
    * 1    LWP 1244450 "attach-non-stop" 0xf1b443bf in ?? ()
      2    LWP 1244453 "attach-non-stop" (running)
      3    LWP 1244454 "attach-non-stop" (running)
      4    LWP 1244455 "attach-non-stop" (running)
      5    LWP 1244456 "attach-non-stop" (running)
      6    LWP 1244457 "attach-non-stop" (running)
      7    LWP 1244458 "attach-non-stop" (running)
      8    LWP 1244459 "attach-non-stop" (running)
      9    LWP 1244461 "attach-non-stop" (running)
      10   LWP 1244462 "attach-non-stop" (running)
      11   LWP 1244463 "attach-non-stop" (running)
    (gdb)
    (gdb) interrupt -a
    (gdb)
    *nothing*

    The problem is that attaching installs an inferior continuation,
    called when the target reports the initial attach stop, here, in
    inf-loop.c:inferior_event_handler:

          /* Do all continuations associated with the whole inferior (not
             a particular thread).  */
          if (inferior_ptid != null_ptid)
            do_all_inferior_continuations (0);

    However, currently in non-stop mode, inferior_ptid is still null_ptid
    when we get here.

    If you try to do "set debug infrun 1" to debug the problem, however,
    then the attach completes correctly, with GDB reporting a stop for
    each thread.

    The bug is that we're missing a switch_to_thread/context_switch call
    when handling the initial stop, here:

      if (stop_soon == STOP_QUIETLY_NO_SIGSTOP
          && (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_STOP
              || ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP
              || ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_0))
        {
          stop_print_frame = true;
          stop_waiting (ecs);
          ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
          return;
        }

    Note how the STOP_QUIETLY / STOP_QUIETLY_REMOTE case above that does
    call context_switch.

    And the reason "set debug infrun 1" "fixes" it, is that the debug path
    has a switch_to_thread call.

    This patch fixes it by moving the main context_switch call earlier.
    It also removes the:

       if (ecs->ptid != inferior_ptid)

    check at the same time because:

     #1 - that is half of what context_switch already does

     #2 - deprecated_context_hook is only used in Insight, and all it does
          is set an int.  It won't care if we call it when the current
          thread hasn't actually changed.

    A testcase exercising this will be added in a following patch.

    gdb/ChangeLog:

            PR gdb/27055
            * infrun.c (handle_signal_stop): Move main context_switch call
            earlier, before STOP_QUIETLY_NO_SIGSTOP.

-- 
You are receiving this mail because:
You are on the CC list for the bug.