Hi, Tested with: GNU gdb (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 8.1.0.20180315-git Is it allowed for the MI interpreter to send 2 result records for the same command? The following output is from an Eclipse/CDT-frontend running the above gdb instance with "--interpreter mi" as parameter. The instance connects to an RSP/JTAG stub over TCP. 522,256 40-exec-continue 522,267 40^running 522,267 *running,thread-id="all" 522,267 (gdb) 522,267 ~"Note: automatically using hardware breakpoints for read-only addresses.\n" 522,284 &"Warning:\n" 522,285 &"Cannot insert hardware breakpoint 5.\n" 522,285 &"Cannot insert hardware breakpoint 10.\n" 522,285 &"Cannot insert hardware breakpoint 2.\n" 522,285 &"Cannot insert hardware breakpoint 9.\n" 522,285 &"Could not insert hardware breakpoints:\n" 522,285 &"You may have requested too many hardware breakpoints/watchpoints.\n" 522,286 &"\n" 522,286 40^error,msg="Command aborted." GDB seems to report "40^running" regardless of the success/failure of the command. "GNU gdb (GNU Tools for ARM Embedded Processors (Build 17.03)) 7.10.1.20160923-cvs" Do not have this problem.
I get the same error on X86-6 using HEAD gdb. $ ./gdb -i=mi -x testcmds a.out Then type "continue" Where "a.out" has >40 lines in the main source file and testcmds contains: b main r hbreak 1 hbreak 2 hbreak 3 hbreak 4 hbreak 5 hbreak 6 hbreak 7 hbreak 8 hbreak 9 hbreak 10 hbreak 11 hbreak 12 hbreak 13 hbreak 14 hbreak 15 hbreak 16 hbreak 17 hbreak 18 hbreak 19 hbreak 20 hbreak 21 hbreak 22 hbreak 23 hbreak 24 hbreak 25 hbreak 26 hbreak 27 hbreak 28 hbreak 29 hbreak 30 hbreak 31 hbreak 32 hbreak 33 hbreak 34 hbreak 35 hbreak 36 hbreak 37 hbreak 38 hbreak 39 hbreak 40
Looking in infrun.c proceed() { ...stuff.... set_running (resume_ptid, 1); // This raises a target_resumed event // causing MI to print the "^running" message // in mi_on_resume_1 ...more stuff... started = start_step_over (); // This causes the breakpoints to get re-inserted. // Which fails, causing the abort ...even more stuff... } I've got no idea how difficult it would be to delay the "^running" until the step_over and what side effects it would cause. Will leave for someone else to comment.
I did some debug of (GNU gdb (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 8.1.0.20180315-git) and found the following: In function Proceed() in file infrun.c: The call to set_running(), which outputs the "running" replies, are done long before the breakpoint installation (Z packets) done somewhere via the call to keep_going_pass_signal(). In older GDBs, for instance 7.10.1, the breakpoint installation seems to be part of success/failure of the initiating command. Im not sure if this is new expected behavior or if its a bug!? To me (with very limited knowledge of the internal of GDB) it looks like GDB outputs a faulty "^running, *running" sequence? This also applies to all "exec-"-commands involving breakpoint installation. Im not sure how an MI-frontend like Eclipse/CDT should be able to handle this.
*** Bug 25725 has been marked as a duplicate of this bug. ***
This area is a bit weird. There's some dubious special code in MI: /* This is what gdb used to do historically -- printing prompt even if it cannot actually accept any input. This will be surely removed for MI3, and may be removed even earlier. */ if (current_ui->prompt_state == PROMPT_BLOCKED) gdb_puts ("(gdb) \n", mi->raw_stdout); Relatedly it prints ^running near here. I haven't really investigated this but I think cleaning this up would be a welcome improvement if it was conditional on MI3 or something like that.