[Bug gdb/20039] Using MI/all-stop, can't interrupt multi-threaded program after continue

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

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

--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-7.11-branch branch has been updated by Simon Marchi
<simark@sourceware.org>:

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

commit f0a8d0dc70eddbf1e323e8c07f5092ff5e327548
Author: Simon Marchi <simon.marchi@ericsson.com>
Date:   Tue May 17 17:07:20 2016 -0400

    Fix double prompt output after run control MI commands with mi-async on (PR
20045)

    When you use a run control command (-exec-run, -exec-continue,
    -exec-next, ...) with mi-async on, an extra (gdb) prompt is displayed:

      -exec-continue
      ^running
      *running,thread-id="all"
      (gdb)
      (gdb)

    It doesn't seem to be a big problem for front-ends, since this behavior
    started in gdb 7.9 and we haven't heard anything about that.  However,
    it caused me some trouble while writing a test for PR 20039 [1].

    The problem comes from an extra (gdb) prompt that we write when running
    in mi-async off mode to emulate a past buggy behavior.  When executing a
    run control command synchronously, previous gdbs always printed a prompt
    right away, even though they are not ready to accept new MI commands
    until the target stops.  Only at this time should they display a prompt.
    But to keep backwards compatibility apparently, we print it anyway.
    Since commit 198297aaf, the condition that decides whether we should
    print that "bogus" prompt or not has become true, even when running with
    mi-async on.  Since we already print a prompt at the end of the
    asynchronous command execution, it results in two prompts for one
    command.

    The proposed fix is to call target_can_async_p instead of
    target_is_async_p, to make the condition:

      if (!target_can_async_p () || sync_execution)
        ... show prompt ...

    That shows the prompt if we are emulating a synchronous command on top
    of an asynchronous target (sync_execution) or if the target simply can't
    run asynchronously (!target_can_async_p ()).

    Note that this code is changed and this bug fixed by Pedro's separate
    console series, but I think it would be nice to have it fixed in the
    mean time.

    I ran the gdb.mi directory of the testsuite with mi-async on and off, I
    didn't see any regressions.

    gdb/ChangeLog:

        * mi/mi-main.c (mi_on_resume): Call target_can_async_p instead
        of target_is_async_p.

    [1] https://sourceware.org/ml/gdb-patches/2016-05/msg00075.html

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