Tracking issue: global-only reverie w/ API v1

[rrnewton]

[Tracking issue. Please edit me to reflect the current set of tasks to make this happen. Factor out and link other issues as appropriate.]

The goal here is to have "API v1" or some evolution of it, working in a degenerate mode:

• All state (global, process, thread) is stored inside the tracer.
• All events in the guest trap to the tracer (like DetTrace).
• The tool is loaded into tracer memory, all event handlers are called in the tracer. They are passed their states from the globle table.
• RPC messages are fake -- they become regular method calls on the global state object, but with a wrapper that makes them look like RPCs.

Here are the tasks to make it happen:

• Load the same tool code in to tracer memory (can even NOT put it in guest address space for the global-only prototype).
• ...
• ...

[rrnewton]

The first consumer of the prototype here will probably be @krs85. She can see if the parallelDettrace prototype can work equally well on this global-only version of Reverie as it can on Ptrace directly. Trying to connect the two will probably result in a stream of requests to expand the API to match more of ptraces capabilities...

[wangbj]

• allow running the same tool in tracer's memory space, or at least make code much more re-usable
• write more usable APIs so that the tool can have their own global/process states
• make the tool event driven: send notifications so that the tool can decide what to do when task state changes
• use future in tracer

[rrnewton]

Part of our goal with the host-only Reverie is to make an effort to mock up the API that host/guest hybrid Reverie will use, and therefore have a reference implementation. Part of that story is how the tool gets built --- what's a cargo library, what's an executable, etc. @wangbj, could you clarify here or on some other Reverie issue what the plan for building the tool is in the future?

Below I'm copying some text over from elsewhere with my take on it:

---

One thing that is not described above is the SEPARATION of the tool into no_std/std parts. That is, I believe code from a tool must be compiled into THREE pieces:

1. In-guest no-std binary implementing handle_event and built with no_std (for now).
2. The same code as (1) but perhaps compiled differently to be linked or loaded into the tracer.
3. A third piece of code that implements the receive_rpc functionality and only needs to exist inside a centralized guest or tracer process, allowing it to use full std, which needs to be linked/loaded into the tracer along with (2).

With the host-tool branch, I think @wangbj is moving towards compiling (2) by simply making Reverie a library and letting the tool build and link the executable that becomes the tracer/launcher.

I notice now one thing missing from the current Reverie API v1 proposal: the code for (3) needs to be split out into a separate trait / object. That is, I don't think we can have one SystraceTool trait that includes both handle_event and receive_rpc. The former needs to be built with no_std for context (1), and the latter needs to be built with std for context (3).

There has to be some way to say "this code only implements the local side of the tool", and then when building the centralized part of the tool (2 & 3), both the local & global functionality is needed. However, even the local code needs to agree on the datatypes for GlobMethodArgs/GlobMethodResult in order to send/receive RPCs on the global state object.