Robert O'Callahan

This really belongs in another thread. Filed https://github.com/rr-debugger/rr/issues/3705

Generally we don't support continuing through an exec. So I don't get this behavior, I see us just stop at the exec without errors, which is expected.

My guess is that llvmpipe is using gdb's "JIT interface" to support debugging of the JITted code and gdb's JITted code support does not work with rr. https://llvm.org/docs/DebuggingJITedCode.html You could...

I've had a brief look at this. It's not the same bug as before, because I can reproduce it with all `to_string` parameters set to false. Also, this bug is...

I think ideally we'd run a lot of code in the tracee that does non-traced syscalls to set everything up, and then does one traced syscall similar to rrcall_init_buffers that...

Of course to get that to work we'd have to arrange for the replay code to match the recording code "closely enough". I need to think about that some more....

Another issue is that we'd have to maintain compatibility with existing syscallbuf recordings. Not sure how much extra work that would be.

The approach I'm planning to try: issue a series of privileged, untraced syscalls to set up the desched fd, the clonedata fd, and a `MAP_ANONYMOUS` `MAP_SHARED` mmap for the syscallbuf,...

https://github.com/rr-debugger/rr/tree/threads has code that works --- passes tests, avoids the roundtrips. However on a test with 2000 threads that start and don't exit, we're still pretty slow: the patch improves...

With those optimized plus another couple of optimizations, the time to create 2000 threads is down to 8s. Basically when there are thousands of threads doing things that are O(number...