[Bug gdb/18077] Using -exec-run with mi-async on results in synchronous execution

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

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

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

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

commit 61c6156df6e3c638eb3bdb4a6e3d418a43a6eb70
Author: Simon Marchi <simon.marchi@ericsson.com>
Date:   Tue May 17 16:44:57 2016 -0400

    Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077)

    When doing -exec-run on a freshly started GDB, the only target on the
    target stack at the time the dummy one.  When mi_async_p is called to
    know whether the run should be async, it queries whether the current
    target (dummy) supports async, and the answer is no.  The fix is to make
    the code query the target that will be used for the run, which is not
    necessarily the current target.

    No regressions in the gdb.mi directory using the unix, native-gdbserver
    and native-extended-gdbserver boards.  The test doesn't pass when
    forcing maint set target-async off, obviously, since it makes mi-async
    have no effect.  It doesn't seem like other tests are checking for that
    eventuality, so I didn't in the new test.

    gdb/ChangeLog:

        * mi/mi-main.c (run_one_inferior): Use run target to determine
        whether to run async or not.
        (mi_cmd_exec_run): Likewise.

    gdb/testsuite/ChangeLog:

        * gdb.mi/mi-async-run.exp: New file.
        * gdb.mi/mi-async-run.c: New file.

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