Projects and priorities
robert at ocallahan.org
Wed Jul 23 17:22:31 PDT 2014
The background to Chris' email, for those who haven't been following rr
commits, is that Chris just fixed #605, allowing gdb to run debuggee
functions during replay. That means we are almost at the point where rr+gdb
lacks no important features compared to gdb alone (for 32-bit targets
anyway), and IMHO that milestone merits a major release. Hurrah!
I just remembered that one missing feature which would be important for
some users is the ability to read FP and SSE registers via gdb. So I think
someone should probably add that before we release 2.0. I'd also like to
get some experience using #605 in Gecko debugging to be confident it's
working well, then let's release 2.0.
On Thu, Jul 24, 2014 at 6:29 AM, Chris Jones <jones.chris.g at gmail.com>
> Projects that would have a big user impact, in priority order
> - already underway: finish x86-64 support. Merits its own major
> release. It's not quite clear to me yet where, or if, additional
> developers can contribute to this effort.
I'm sure many people can contribute. I'll post a followup-email about that.
- add reverse-continue/reverse-step/et al. support. Merits its own major
> release. First step should be a wiki page with a design overview.
I've thought about this quite a bit so I'll create that page.
Projects that would have some user impact, in no particular order
> - compress traces. (Consume up to 40x less space.)
My laptop's SSD just died and while the hardware claims to be nowhere near
the wear-levelling limit, I'm suspicious that rr's heavy write workload may
have contributed. The tremendous wins here for not much effort make this
little project quite appealing to me. Having said that, I doubt trace size
is discouraging anyone from using rr at the moment (except perhaps for
people who read this paragraph :-) ).
BTW if we do this, I recommend also moving away from C++ streams, mainly
because currently the open fds for the trace files leak into the fd space
of tracees and there's no way to make the fds for C++ streams CLOEXEC
AFAICT. Such leaks are not a big deal but they make dirtier output when
studying tracees using lsof and admit some truly obscure potential bugs.
- finish implementing gdb's "machine interface" (gdb-mi) , to support
> Eclipse and emacs gud-gdb debuggers
> Projects that would help developers, in priority order
> - code cleanups. Especially migrating verbose C-idiom code to C++.
I've got some ideas about this that I've already posted, and some more I'll
> - switch to using instructions-retired counter instead of
> retired-conditional-branches . This solves a variety of practical and
> theoretical problems.
Do you have a plan for overcoming the problems with the
instructions-retired counter that stopped us from using it already?
Projects with a research-y direction, in ~priority order
> - chroniclerr: hack rr to support "omniscient debugging" . Needs
> better UI for full power.
> - on top of chroniclerr infrastructure, allow running valgrind tools over
> rr traces (i.e. ex post facto valgrind). Possibly related to recent work
> with PANDA.
> - start on tech report or academic-style paper describing rr and results
> There's a long tail of not-necessarily-high-priority stuff, some of which
> is listed here .
> Anything to add, or suggestions about priority?
Another project which would be interesting and might increase rr usage at
Mozilla is to build an agent for the remote JS debugging protocol on top of
rr. The ability to run tracee code should make this a much easier
proposition! If we added reverse-execution commands to the protocol we
could make something that would potentially be a neat product for Mozilla
(a bit limited due to rr only running on Linux, but we could supply a VM
image with Firefox+rr that you can connect to from outside the VM). Might
be a good Mozilla intern project. Unclear how hard this would be, but
getting something useful might not be very hard.
I'm a bit frustrated that rr hasn't taken over the world yet even though
I'm happily using it regularly (which is a first for any research-y tools
I've built!) :-). So my personal priorities are to keep knocking down
barriers to adoption by current gdb users (like me and other Mozilla
Gecko-on-Linux hackers), and to find the best bang-for-buck feature wins
for those users. Fixing #605 is a giant step forward for my usage. x86-64
knocks down an obvious adoption barrier. rstepi/rcontinue support is
probably the next best bang-for-buck feature. So those are my personal
priorities for the immediate future, in that order. I'm also interested in
doing some code cleanup along the way since I feel my development is a
little taxed at the moment and I think we could make the code significantly
Once we've implemented rstepi/rcontinue for gdb I feel like we'll have
taken gdb about as far as we can. I have big dreams for much better
debugging tools but without a serious investment of resources I think, in
practice, they won't beat the super-gdb that is within our reach. That's
why chroniclerr is not a priority for me personally at this time.
Of course I have no objection to people working on their own priorities. :-)
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
otohoeo ofoioroeo ooofo ohoeololo.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rr-dev