Differences between revisions 17 and 18
Revision 17 as of 2014-07-31 18:52:41
Size: 2995
Editor: TomTromey
Comment: update status to reflect newer branch
Revision 18 as of 2015-07-23 19:42:56
Size: 3030
Editor: PaulKoning
Comment: Add pointer to where the current code lives.
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Line 6: Line 5:
Line 10: Line 8:

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.
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.  These branches can be found at https://github.com/tromey/gdb/
Line 15: Line 11:

Line 20: Line 14:
  * ctf, tfile, and record are not handled yet
Line 21: Line 16:
   * 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.
Line 23: Line 18:
   * 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
Line 25: Line 20:
   * 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
  * other targets exist but should first be converted to target-async by an interested party
Line 38: Line 31:
  1. Currently the branch has {{{add-inferior -new-target}}}. This seems ok, though it requires the user to plan a little in advance.
Line 39: Line 33:
  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.
  1. 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.
Line 47: Line 39:
 * The frame cache should probably be per-target (though see [[Sourceware:PR7573]] -- perhaps the it should be per-address space instead).  * The frame cache should probably be per-target (though see Sourceware:PR7573 -- perhaps the it should be per-address space instead).
Line 54: Line 46:

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 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. These branches can be found at https://github.com/tromey/gdb/

Plan

  • 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:
    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.

  • 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


OngoingWork

None: MultiTarget (last edited 2015-07-23 19:42:56 by PaulKoning)

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