This page describes the multi-target project, aka PR7250.
This project aims to make it possible for users to connect to multiple targets at once. For example, a user could connect to multiple gdbservers at the same time; or freely mix native, remote, and core-file debugging.
The multi-target branch is mostly dead. I salvaged some work from it on the multi-target-corelow branch, which see. This latter branch doesn't include the ptid_t changes -- and perhaps those should be redone from scratch anyway, it is unclear.
Parameterize global state for corelow.c (this is done on both branches)
- ... and likewise for all the desired targets.
- ctf, tfile, and record are not handled yet
remote.c still records info in the global remote_protocol_packets. This must be made per-target.
- remote-notif.c probably needs to be made per-target
- other targets exist but should first be converted to target-async by an interested party
Add target identity and change target stack introspection functions to examine it
Turn the needed targets into to_xclose targets. The branch has this for a few. Note that "nat" targets need not be converted in this way, as they are inherently singletons. There's a hack on the branch to account for this (look for the "child" comparison).
Convert current_target to be a pointer. This makes it cheap to switch targets.
Make the target stack be reference counted; and attach it to the program space.
- Have a user-interface for connection to a new target. Two ideas:
Currently the branch has add-inferior -new-target. This seems ok, though it requires the user to plan a little in advance.
Another idea is a COW target stack. Then an ordinary add-inferior would work, and a call to to_open with a process stratum target would potentially make a copy of the target stack first. The only wrinkle here is that to select the native target we would have to add a new target child command.
- Change gdb to handle the same PID coming from multiple targets. The basic change to ptid is done on the old branch, more may be required, or perhaps it should be done in a different way.
- Need to iterate across targets in various cases: stop processes on all targets when one stops (in all-stop); resuming; maybe C-c handling; quit
The frame cache should probably be per-target (though see PR7573 -- perhaps the it should be per-address space instead).
Maybe this requires a fix for PR7251, making it possible for target commands to be interrupted. At the very least it seems like a nice-to-have. We possibly want to allow the "&" suffix for target commands to make them connect asynchronously.
- Write tests and documentation