RR API Discussion (librr)

Chris Jones jones.chris.g at gmail.com
Mon Oct 13 20:48:14 PDT 2014


On Mon, Oct 13, 2014 at 5:33 PM, Benoit Girard <bgirard at mozilla.com> wrote:

> More importantly what API should rr provide?
>

​Do you mind enumerating your use cases for recording and replay?  That
would help drive this discussion.

​The way I wanted to organize rr's internals was around two interfaces: a
driver and an event observer.  After each event, the driver would tell the
core how to resume execution.  Then on reaching the next event, the core
would notify the event observer.  I imagine this being a visitor-style
class with interface methods to notify signals, syscalls and arguments read
into tracer memory, ptrace events, etc.  The simplest possible consumer
would be an strace clone.  The driver for strace-clone would simply resume
"all threads" every time.  The event observer would simply print whichever
event occurred.  For rr, the recording driver would schedule a single
thread to resume, and the replay driver would peek ahead at the next trace
frame to choose a thread (and check if the debugger wanted to single-step
etc.).  The recording event observer would save the events to trace, and
the replay observer would assert that the event was the same as in trace
(and drop extraneous signals etc.)  This core would essentially be a linux
introspector, which I think would be interesting for researchers etc in the
same way that valgrind is.  In the future we could extend this core to
allow consumers to instrument tracee code, which we want for chroniclerr.

The next-level API would essentially be what roc describes.  I think that
Session-style API should allow consumers to extend the data that's saved to
trace at each event.  That's how I would implement a tool like a
super-precise profiler: save various perf counters along with each trace
event.

I also think we should have an API for just iterating trace events and
their ancillary data, which is useful for analysis tools.  |rr dump| and
|rr dump -r| do this in a non-extensible way, and I've written really
useful tools on top of them.

I agree that it sounds like #1330 is best served by a Session-level API, so
feel free to ignore my comments about the lower-level API :).

Cheers,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20141013/5e502b9c/attachment.html>


More information about the rr-dev mailing list