rr-debugger
Add commands to explicitly start and stop diversions
I'm trying to intentionally diverge from a replay by tweaking a variable but I get the following error: Attempt to write memory outside diversion session
I did some searches online and just found roc' blog: http://robert.ocallahan.org/2014/09/rr-20-released.html
It seems you can diverge for 'call' but not 'set'.
Ideally I'd like to do something like this: diversion start set shouldPrint = true cont <...> diversion end
That could easily be implemented as a new feature. You probably don't want to mess with the horrible heuristics that trigger automatic divergence for call.
Yea, I might be interested in picking this up if we can come up with a good design for it. Seems like it wouldn't be hard to implement now (right?) if we let the user explicitly request diversion. Then we can update the error message to suggest the diversion command.
To be more explicit I was implying that 'diversion start' would be an implicit 'checkpoint' + create a diversion session and 'diversion end' would 'restart $cp_id'.
Yes, the main thing that's needed here is a new "diversion start" command that spawns a diversion and runs the diversion session until we get an explicit "diversion end" command. It should reuse DiversionSession but not reuse the logic that currently triggers and terminates DiversionSessions (diverter_process_debugger_requests).
You don't actually need an explicit checkpoint; just clone the current ReplaySession to a DiversionSession, drive that to a conclusion, and then destroy it.
I had a look at this. I call gdb_server.timeline.current_session().clone_diversion();. Now I was thinking that logically I could swap the current and diversion session in the timeline during the length of the diversion. This would let the GdbServer dispatch all incoming commands to the diversion session without any invasive changes like diverter code you menitonned. However DiversionSession does not derive from ReplaySession but rather they both derive from a common ReplaySession.
Ahh nevermind. I think I see that DiversionSession is a lot more limited than what I had imagined. It's probably not worth adding reverse execution support to them. At least not yet.
It does mean however that the GdbServer request handling need to check if there any active diversion. GdbCommands like history and checkpoint will probably need to change their behavior as well.
Reverse execution within a DiversionSession doesn't really fit the model. That would require recording during a DiversionSession.
We might want to factor out some code to make it easier to write GdbServer code that operates on either a DiversionSession or the timeline's current session.
I'll set this aside for now since I have another way of getting what I need. If someone wants to pick it up feel free.
I'm completely clueless on how hard would it be to implement or how realistic is the expectation, but being able to diverge from the recorded execution, while also having reverse-continue working would be amazing! @rocallahan you said implementing diverging is easy ("That could easily be implemented as a new feature"), but how hard do you think it'd be to implement diverging + reverse-continue support in a diverted session? I'd be happy to help implementing this if I wasn't behind the schedule this bad :) But if you say this is still easy maybe I can allocate some time for this (note: I've never even looked at rr source yet, so this may not be a good task for me).
This feature would be nice.
Actually I don't understand what the gdb_server is about (trying to call python gdb_server just get Error occurred in Python: name 'gdb_server' is not defined, but at the moment you can use the following as a workaround:
-
diversion start→ just call any harmless function e.g.call (int)printf("") -
diversion end→ just do anything that change the state e.g.stepi→reverse-stepi
