GDB Multiple MI responses for same command

Asked by Anders Jansson on 2019-03-20


Tested with: GNU gdb (GNU Tools for Arm Embedded Processors 7-2018-q2-update) Latest build also seems to have this behavior.

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 report "40^running" regardless of the success/failure of the command. Some debugging show that GDB always seems to report the "^running..." result record (in mi_on_resume) for the "exec-continue" long way before communicating the "Z" packets to the RSP-stub. This makes it hard for the MI front-end to determine the success/failure of the "exec-"-commands in the case when to many breakpoints are set in target hardware..

"GNU gdb (GNU Tools for ARM Embedded Processors (Build 17.03))" Do not have this problem.

Question information

English Edit question
GNU Arm Embedded Toolchain Edit question
No assignee Edit question
Last query:
Last reply:
Launchpad Janitor (janitor) said : #1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.