Differences between revisions 15 and 16
Revision 15 as of 2014-02-12 19:44:53
Size: 2659
Editor: TomTromey
Comment: remove incorrect info
Revision 16 as of 2014-02-19 19:44:42
Size: 3251
Editor: TomTromey
Comment: mention some needed changes
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:

== Status ==

The branch needs a bit of a rework. Given the changes on master it should probably just be started over, cherry-picking the useful bits. Particular things to change would be:

 * Currently the branch does a lot of work to remove {{{to_beneath}}}. However if the {{{target_ops}}} / {{{gdb_target}}} split is done earlier in the series, then {{{to_beneath}}} can live on in {{{gdb_target}}}.

 * {{{find_default_run_target}}} and friends need special treatment. In particular they need to properly instantiate a target. I think this isn't done on the branch at all.

Multiple Targets

This page describes the multi-target project, aka PR7250.

Goal

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.

Status

The branch needs a bit of a rework. Given the changes on master it should probably just be started over, cherry-picking the useful bits. Particular things to change would be:

  • Currently the branch does a lot of work to remove to_beneath. However if the target_ops / gdb_target split is done earlier in the series, then to_beneath can live on in gdb_target.

  • find_default_run_target and friends need special treatment. In particular they need to properly instantiate a target. I think this isn't done on the branch at all.

Plan

  • Parameterize global state for corelow.c (this is done on the branch)

  • ... and likewise for all the desired targets.
    • ctf, tfile, and record are not handled yet on the branch
    • remote.c still records info in the global remote_protocol_packets. This must be made per-target.

    • other targets exist but should first be converted to target-async by an interested party
  • Get rid of target_ops::beneath. This lets us reuse a target_ops in multiple target stacks.

  • 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:
    1. Currently the branch has add-inferior -new-target. This seems ok, though it requires the user to plan a little in advance.

    2. 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.

  • The branch also has a big patch to split target_ops into state and vtable components. This isn't strictly needed but it makes gdb cleaner.

  • Fix up the target dcache to be per-target-stack. (Fixed by Yao's patch which will go into master.)

  • Change gdb to handle the same PID coming from multiple targets. The basic change to ptid is done here, more may be required.
  • 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.

  • Also see PR15712 - making target-async enabled by default. Async is needed for multi-target to work nicely.

  • Write tests and documentation


OngoingWork

None: MultiTarget (last edited 2014-02-19 19:44:42 by TomTromey)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.