> gdb has had reversible debugging since release 7, in 2009. What does udb offer that it lacks?
GDB's built-in reversible debugging is cool (and it's helped raise awareness) but it doesn't scale well. We build on the same command set and serial protocol that GDB defined - UDB is GDB but with additional Python code hooking it up to our separate record/replay engine.
For UDB, I'd say we offer:
1. Performance & efficiency (orders of magnitude faster at runtime and lower in memory requirements).
2. Recordings can be saved to portable files (share with colleagues, receive from customers, etc).
3. Library API so applications can self-record with control of when to capture and save.
4. Wider support of modern software (proactively tracking modern CPU features, shared memory and device maps, etc).
5. Correctness (in the past we've found the reverse operations in GDB don't have as strong semantics as we'd hoped, though I'd also be happy to be wrong here)
FWIW, rr (https://rr-project.org/) also offers many similar benefits over GDB's built-in system (though not the library API in point 3) but with differences in what CPUs / systems are supported, ability to attach at runtime, etc.
If you're looking for an open source solution, I'd choose rr over GDB's built-in approach.
I'm not familiar with udb, only with rr. Compared to rr, gdb's recording for reversible debugging is tremendously slower. However rr has strict requirements for the CPU (didn't work on AMD, the last time I looked) and requires some permissive perf_event_paranoid setting to run.
In my experience rr's recording is around x2 slower for single threaded programs than running the program on its own.
I think featurewise they are in parity.
I heard that udb is like rr, but better on some fronts (except price and software freedom).
> gdb has had reversible debugging since release 7, in 2009. What does udb offer that it lacks?
GDB's built-in reversible debugging is cool (and it's helped raise awareness) but it doesn't scale well. We build on the same command set and serial protocol that GDB defined - UDB is GDB but with additional Python code hooking it up to our separate record/replay engine.
For UDB, I'd say we offer: 1. Performance & efficiency (orders of magnitude faster at runtime and lower in memory requirements). 2. Recordings can be saved to portable files (share with colleagues, receive from customers, etc). 3. Library API so applications can self-record with control of when to capture and save. 4. Wider support of modern software (proactively tracking modern CPU features, shared memory and device maps, etc). 5. Correctness (in the past we've found the reverse operations in GDB don't have as strong semantics as we'd hoped, though I'd also be happy to be wrong here)
FWIW, rr (https://rr-project.org/) also offers many similar benefits over GDB's built-in system (though not the library API in point 3) but with differences in what CPUs / systems are supported, ability to attach at runtime, etc.
If you're looking for an open source solution, I'd choose rr over GDB's built-in approach.