Currently the sims don't implement target-async, but they could. There are three ways to do it. The first way keeps the current restriction that only a single sim can be used at a time. The idea is simple -- run the simulator code in a separate thread, doing whatever locking is needed on the gdb side. On the sim side this may need a bit of auditing to make sure that the code is "thread safe enough"; plus some minor changes to prevent the sims from installing their own signal handlers. The second way would also be to use multiple threads, but do more auditing on the simulator code to (1) let multiple instances of a given simulator run at once, and (2) let multiple simulators be built and linked in (or dlopen'd) at the same time. The third idea is to add a minimal RSP stub to the various drivers (run.c, nrun.c, plus there is at least one custom one in tree) and change "target sim" to be a wrapper around "target remote". Some tricks -- perhaps threads again -- are needed here to make C-c work properly; also this may break the sim command completion functionality.
all enhancements should be routed through nrun from now on. the run interface is being killed off, and ports that have custom entries (like erc32) simply wouldn't get support for this new functionality imo.
See also bug #7505. I lean toward the RSP approach nowadays; we could remove remote-sim entirely. The only really tricky thing here, I think, is handling the sim-specific gdbarch register remapping: Method( comment=""" MAP a GDB RAW register number onto a simulator register number. See also include/...-sim.h. """, type="int", name="register_sim_regno", params=[("int", "reg_nr")], predefault="legacy_register_sim_regno", invalid=False, ) This is used in a few arches, search for set_gdbarch_register_sim_regno. Probably the best approach is to just change the sims to use XML register sets like everything else.
seems we're getting a little off topic from the bug as defined ("sims not target-async"). i've looked at the xml/regnum issue in the past to see if it could be cleaned up. i filed bug 29869 to track that work & my thoughts.