Feasibility of record while debugging?

[Christophe Guillon]

Hi,

I'm wondering whether it would be feasible to have the the rr tracer/interposition working directly in a debugging session (on the executable itself, not a rr trace), or an equivalent which would allow to record and reverse debug while the program is not yet terminated,

optionally at some point letting the program finish its recording up to the program exit.

I.e. not being forced to record first before replay/debug.

This would be different from the other use case of a long running program for which we would attach and collect partial trace before debugging.

Actually the use case would be the equivalent of the gdb record command, i.e. for instance:
$ gdb ./main.exe

(gdb) start
(gdb) record full      # activate full trace (maybe mandatory at start with rr)
(gdb) next                # here execute to next and also records to the trace
(gdb) reverse-next  # here walks back the trace only and stop
(gdb) continue        # here walks the trace to current end of trace and continue exec and record until exit
(gdb) [exited[

I suppose that it may at least complicate significantly the interposition code in order to be able to both record and replay at the same time.

Though, is there a fundamental show stopper for this use case that one could point out?

Br,

Christophe Guillon

[Robert O'Callahan]

There's no *fundamental* showstopper since UndoDB does it. But it would be a lot of work.

We've felt that the separate recording step works well with most workflows. What's the use-case where it's a problem?

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.

[Christophe Guillon]

Hi,

thanks for the answer, we might have a look at UndoDB and possibly study feasibility on rr implementation, but indeed our use case is probably marginal.

Actually, we are working on the early stages of a tool for program control, inspection and visualisation, in the field of teaching mainly (program state visualization). Though could be used for program testing also (i.e. external verification of program state).

Not in the field of debugging exactly, though we use debuggers for statically compiled languages as in this case it is the most efficient way to control and introspect programs.

Basically we have a controller program which uses a hopefully simple API in python to put observation points and react on these in order to visualize states or in turn add or change observation points.
The API is agnostic to the underlying inferior language in order to ease reuse for different languages as seen in teaching courses.

On the "trace" side of the applications range, we want something more controllable than a full trace, such a PythonTutor does, because most of the time we want to show (or generate slides) for partial states of a program.

On the more "dynamic" side of the application range, we use it for a game to learn finding bugs in a code base (serious games) where the program is itself a game and the visualization of the state is thus interactive and augmented with some control and introspection commands.
In this case actually we want a level of the game to run, with user interactions, but it would also be useful for the user to step back (even read only) to understand what happened in the past in the program, before going further.
Gdb or our own API can record all steps but this is very slow, hence the question on whether RR could record/reverse/replay at the same time.

Thanks,

Christophe