Bug 18077 - Using -exec-run with mi-async on results in synchronous execution
Summary: Using -exec-run with mi-async on results in synchronous execution
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.8
: P2 normal
Target Milestone: 7.11.1
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-03 16:21 UTC by Simon Marchi
Modified: 2016-07-28 09:17 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Test case .exp (899 bytes, text/plain)
2015-03-03 16:26 UTC, Simon Marchi
Details
Test case .c (498 bytes, text/x-csrc)
2015-03-03 16:26 UTC, Simon Marchi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Marchi 2015-03-03 16:21:26 UTC
Using this simple test program:

    int main()
    {
        for (;;);
        return 0;
    }

And trying these commands:

    $ gdb -nx -i mi a.out
    -gdb-set mi-async on
    -exec-run
    -exec-interrupt --all  <--- It doesn't work, even though it should since we are in mi-async on mode.


I traced the root of the problem to this line:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/mi/mi-main.c;h=7412f7d8a553ca6739da1480c2e84572f38a8e78;hb=HEAD#l493

At this point, the linux-native run target is not pushed yet. mi_async_p ends up calling tdefault_can_async, which returns false, so we don't execute asynchronously.
Comment 1 Simon Marchi 2015-03-03 16:26:04 UTC
Created attachment 8164 [details]
Test case .exp
Comment 2 Simon Marchi 2015-03-03 16:26:19 UTC
Created attachment 8165 [details]
Test case .c
Comment 3 Simon Marchi 2015-03-03 16:27:31 UTC
I added a test case that I made quickly (copied from mi-async.exp). It passes when I replace the return 0 in tdefault_can_async_p by return 1. It's obviously not the right solution, but I think it shows what the behaviour should be on linux-nat.
Comment 4 Pedro Alves 2015-12-18 11:47:27 UTC
-exec-run should probably call find_run_target() and use that target to check for async support, like infcmd.c:run_command_1 does.
Comment 5 Marc Khouzam 2016-02-16 21:39:22 UTC
I'm very surprised I didn't notice this before.  Probably shows some deficiency in the testing we do.  We always test eclipse with a default breakpoint at "main" which interrupts the execution and then the asynchronous stuff starts to work.

But if I start a non-stop session without any breakpoints (so the execution does not stop on its own), the session is borked; can't set breakpoints, can't interrupt, it doesn't even display completely.
Comment 6 cvs-commit@gcc.gnu.org 2016-05-17 20:55:38 UTC
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.
Comment 7 cvs-commit@gcc.gnu.org 2016-05-17 21:01:19 UTC
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=b5f0db46b3057bcb64243e7da0943717abd6459b

commit b5f0db46b3057bcb64243e7da0943717abd6459b
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.
Comment 8 Simon Marchi 2016-07-27 20:45:32 UTC
Patch is pushed.