=== TODO items for SystemTap+Dyninst ====

* Finish splitting the runtime (PR14179)
- A lot of kernel-specific stuff is moved to runtime/linux/
- More needs to be moved, and implemented in runtime/dyninst/ as needed.

* Restrict the set of available probe types.
- Currently the "bad" types will just lead to pass-4 errors.  We're operating
  without privilege, so there's no security concern, only broken code.
- The useful set will probably be similar/identical to --unprivileged.

* Investigate backtracing support
- Dyninst's instrumentation will likely wreak havoc on our code.
- Does Dyninst runtime provide any support on mutatee side?

* Kill (or reduce use of) the stapdyn_big_dumb_lock.
- A lot of stuff should be per-thread, especially CONTEXT, print buffers.
- For threaded stats and pmaps, how can one collect across all?

* Use a real stapio (lite?) transport layer.
- Make a Dyninst one-time-call to open a mutator<->mutatee socket.
- Send data to mutator, rather than dumping on mutatee stdio.
- Will allow for other two-way commands, maybe removing the need for
  stuff like stp_dummy_init/exit.

* Translator generalization, reducing kernel-isms.
- Generated code should take a more general flavor, that can be implemented on
  either kernel or dyninst runtime interfaces, rather than kernel-flavored code
  that the dyninst runtime has to emulate.

* Support multiple target processes. (follow-fork mode)
- Need to track fork/exec, and insert probe module in each.
- Need to share globals, and solve per-thread access (e.g. collecting pmaps).

* Manipulate SDT semaphores.
- Need BPatch_object::offsetToAddr to be fixed.

* Add return probes.
- Not sure how, maybe Dyninst function wrapping?

* Pass pt_regs to process probes.
- Need to build the struct from BPatch_registers.
- Will require Mike Lam's patch for "special" registers.
- Dyninst may not support modification, so read-only for now.

* Reconcile stapdyn with the systemtap client/server model.

* Reconcile stapdyn with --remote operation.
- Needs to check that the remote has stapdyn at all.
- Probably needs a new stapio command akin to 'run', e.g. 'dyn'.

* Need a deref implementation for memory protection!
- Not sure how to do this, maybe just a SIGSEGV handler?

* Make stapdu_target more flexible
- Current fixed ABI is too limited IMO
- JSON is an idea, but perhaps overkill.
- Simpler idea: just a list of key=value strings, where each probe=TYPE starts
  a new target.  Something like:
    probe=uprobe\0path=/bin/foo\0offset=0x42\0
    probe=uprobe\0path=/bin/bar\0offset=0x84\0
  - I like keeping it textual, but want to avoid too much verbosity too...

* Enumerate more TODO tasks.
