Created attachment 11835 [details] Matrix multiply executable file used OS: Ubuntu 16.04 4.15.0-48-generic Error message: infrun.c:5284: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed. GDB version: 8.3.50.20190605-git, built from source, compiled `--with-python` This error occurs when debugging a Renode (https://renode.io/) simulation of a RISC-V processor as a remote target. Basic setup steps were followed per instructions at https://github.com/renode/renode/blob/master/README.rst (version 1.7.1.41134 of Renode). Target is running a simple matrix multiply benchmark, file included. Steps to reproduce: * start Renode simulation with `renode` * In Renode terminal: - $name?="SiFive-FE310" - mach create $name - machine LoadPlatformDescription @platforms/cpus/sifive-fe310.repl - $bin=@[path_to_executable] - showAnalyzer sysbus.uart0 - sysbus LoadELF $bin - sysbus Tag <0x10008000 4> "PRCI_HFROSCCFG" 0xFFFFFFFF - sysbus Tag <0x10008008 4> "PRCI_PLLCFG" 0xFFFFFFFF - sysbus.cpu PerformanceInMips 320 - sysbus.cpu StartGdbServer 3333 * start gdb with [path_to_repo]/gdb/gdb --data-directory=[path_to_repo]/gdb/data-directory [path_to_executable] * in GDB interpreter: - b mm.c:24 - target remote :3333 - monitor start - continue // verifying breakpoint * simulate the remote target crashing by typing `quit` in Renode terminal * try to `continue` in GDB - reports "Remote connection closed" * restart Renode simulation according to instructions above * try to reconnect GDB to remote with `target remote :3333` * GDB crashes with the above error message Incidental information: This is not actually a bug with the Renode simulator - I am using GDB to flip bits in memory and registers of the running program. Sometimes this causes the PC to jump to 0x00, or something out of the valid section, which crashes the Renode simulation. I would like to be able to restart the simulation and reconnect GDB, since I am scripting GDB with the Python interface.
If this is still an issue, probably the most helpful thing would be the remote protocol logs. You can get these by using "set debug remote 1" before connecting to the remote target.