[Bug gdb/22992] New: GDB and Microsoft Windows thread pool

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/22992] GDB and Microsoft Windows thread pool

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=22992

--- Comment #18 from Tom Tromey <tromey at sourceware dot org> ---
I've sent my patches now.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/22992] GDB and Microsoft Windows thread pool

Sourceware - gdb-prs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=22992

--- Comment #19 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <[hidden email]>:

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

commit 0a4afda3c63687cc5cbbdae78850ee66967cd648
Author: Tom Tromey <[hidden email]>
Date:   Wed Apr 8 14:33:35 2020 -0600

    Handle pending stops from the Windows kernel

    PR gdb/22992 concerns an assertion failure in gdb when debugging a
    certain inferior:

        int finish_step_over(execution_control_state*): Assertion
`ecs->event_thread->control.trap_expected' failed.

    Initially the investigation centered on the discovery that gdb was not
    suspending other threads when attempting to single-step.  This
    oversight is corrected in this patch: now, when stepping a thread, gdb
    will call SuspendThread on all other threads.

    However, the bug persisted even after this change.  In particular,
    WaitForDebugEvent could see a stop for a thread that was ostensibly
    suspended.  Our theory of what is happening here is that there are
    actually simultaneous breakpoint hits, and the Windows kernel queues
    the events, causing the second stop to be reported on a suspended
    thread.

    In Windows 10 or later gdb could use the DBG_REPLY_LATER flag to
    ContinueDebugEvent to request that such events be re-reported later.
    However, relying on that did not seem advisable, so this patch instead
    arranges to queue such "pending" stops, and then to report them later,
    once the step has completed.

    In the PR, Pedro pointed out that it's best in this scenario to
    implement the stopped_by_sw_breakpoint method, so this patch does this
    as well.

    gdb/ChangeLog
    2020-04-08  Tom Tromey  <[hidden email]>

            PR gdb/22992
            * windows-nat.c (current_event): Update comment.
            (last_wait_event, desired_stop_thread_id): New globals.
            (struct pending_stop): New.
            (pending_stops): New global.
            (windows_nat_target) <stopped_by_sw_breakpoint>
            <supports_stopped_by_sw_breakpoint>: New methods.
            (windows_fetch_one_register): Add assertions.  Adjust PC.
            (windows_continue): Handle pending stops.  Suspend other threads
            when stepping.  Use last_wait_event
            (wait_for_debug_event): New function.
            (get_windows_debug_event): Use wait_for_debug_event.  Handle
            pending stops.  Queue spurious stops.
            (windows_nat_target::wait): Set stopped_at_software_breakpoint.
            (windows_nat_target::kill): Use wait_for_debug_event.
            * nat/windows-nat.h (struct windows_thread_info)
            <stopped_at_software_breakpoint>: New field.
            * nat/windows-nat.c (windows_thread_info::resume): Clear
            stopped_at_software_breakpoint.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/22992] GDB and Microsoft Windows thread pool

Sourceware - gdb-prs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=22992

--- Comment #20 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <[hidden email]>:

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

commit 360ad8b3505faea96190283270854bf9b397f334
Author: Tom Tromey <[hidden email]>
Date:   Wed Apr 8 14:33:35 2020 -0600

    Add pending stop support to gdbserver's Windows port

    This changes gdbserver to also handle pending stops, the same way that
    gdb does.  This is PR gdb/22992.

    gdbserver/ChangeLog
    2020-04-08  Tom Tromey  <[hidden email]>

            PR gdb/22992
            * win32-low.c (child_continue): Call matching_pending_stop.
            (get_child_debug_event): Call fetch_pending_stop.  Push pending
            stop when needed.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/22992] GDB and Microsoft Windows thread pool

Sourceware - gdb-prs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=22992

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |10.1
             Status|NEW                         |RESOLVED

--- Comment #21 from Tom Tromey <tromey at sourceware dot org> ---
Fixed.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/22992] GDB and Microsoft Windows thread pool

Sourceware - gdb-prs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=22992

--- Comment #22 from Ruslan Garipov <ruslanngaripov at gmail dot com> ---
Thanks a lot for your huge work!

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