Any chance to sponsor rr feature development?

Robert O'Callahan robert at ocallahan.org
Tue Oct 1 03:13:52 UTC 2019


On Mon, Sep 30, 2019 at 6:00 PM Yichun Zhang <yichun at openresty.com> wrote:

> We've been relying on rr more and more these years. And our company
> (OpenResty Inc.) would like to sponsor and speedup the open source
> development work of those missing features of rr we care the most,
> like 1) the attaching to and detaching from an already running process
> or process tree, and 2) recording/replay support on Aarch64. Is the rr
> team (either individuals or companies) open to such sponsorship?
>

Glad to hear you get a lot of value out of rr!

Not sure exactly who counts as "the rr team", but Kyle and I are very busy
with https://pernos.co. Pernosco uses rr and we would love to have those
features in rr, but unfortunately you've picked some pretty hard ones and I
don't think either of us would be willing to take them on in the forseeable
future.

Aarch64 support depends on the availability of suitable performance
counters, which is at best "unknown". Someone would need to experiment with
specific hardware before anyone could even start porting rr.

Dynamic attach/detach is also very difficult. One issue is that currently
we depend on the "rr page" being at a fixed location in memory for all
recorded processes (our seccomp filter depends on this). That works
currently because we reserve that page immediately after every execve(),
but with a dynamic attach we might find that that page is already being
used by the application. So the first step towards supporting dynamic
attach/detach would be to allow the rr page to be at any address (but the
same address in every process). I think that's doable, but it's already
quite a lot of work. An even bigger problem is syscall buffering: injecting
librrpreload into a running process doesn't sound feasible. Of course you
can give up on syscall buffering, but that adds a lot of overhead. Another
problem is that applications will cache CPUID values, e.g. to indicate that
RTM is available, and then keep on using those features after rr has
attached :-(.

There could be an easier compromise approach where you run everything under
rr all the time, so librrpreload and the rr page are always injected and
CPUID faulting lets us mask CPU features, but rr supports a "non-recording"
mode which allows multiple threads to run with minimal overhead until you
switch on recording. That would not be as flexible as a true "attach"
operation, of course. If that suited your needs, you might be able to find
someone to implement it.

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20191001/27f0f152/attachment.html>


More information about the rr-dev mailing list