Kyle Huey

8a15f2acdd39d799001c98107e72c2bed4ec63e9 may have obviated the need for this.

Note that it doesn't have to be gdb, even with `rr replay -a` we'll use breakpoints internally and that has triggered divergence in the past (e.g. #3030). That it works...

And a DRM module is the sort of thing that would read its own code back to see if it's changed :(

Yeah that was what I came up with in https://github.com/rr-debugger/rr/issues/3030#issuecomment-1013581049. Perhaps we should just do it.

cc @Keno

> I am most interested in how to access/view the memory changes from syscalls. For this particular case `dump -m` will help.

rr doesn't support DRI and that's probably confusing the driver. https://github.com/rr-debugger/rr/blob/90e46d55cf019482d80e27bdbdf57a939d395e14/src/preload/preload_interface.h#L585-L598

If you just need information about syscalls you can probably get that from `rr dump` somehow. I don't think you should need to actually execute the replay.

Ah, ok I understand what you mean now. You might consult https://github.com/firecracker-microvm/firecracker/blob/main/resources/seccomp/x86_64-unknown-linux-musl.json and the documentation at https://github.com/firecracker-microvm/firecracker/blob/main/docs/seccomp.md. That plus rr dump after rr record -n of your program (or just...

Yeah does your system have a header that defines `ps_get_thread_area`?