Robert O'Callahan

It would probably be a fair bit of work to support and that async I/O model is pretty much obsoleted by `io_uring`, so I'm not that interested in implementing this....

Yeah, for a long time I've considered that it might be good to handle signal interruption of buffered syscalls by unwinding the syscall buffering so signal handlers see the "correct"...

*Maybe* we could get away with a set of special stubs that do "syscall; jmp back to application code" which we set the IP to after we've unwound the syscallbuf...

That's pretty much what I had in mind.

> fix that back up on sigreturns. Do you mean unpatch on sigreturns, or adjust the IP on sigreturns? I think the former would be safer right?

OK. I wonder how you handle the trailing instructions of the syscall hooks.

``` 0x7f740003a000 0x7f7404000000 0x3fc6000 0x0 0x7f7407a00000 0x7f7407c00000 0x200000 0x0 ``` so `0x7f74079ca0b0` doesn't look valid to me. Using `hbreak` instead of `break` can usually work around problems like this as...

I don't know. Try replaying with `RR_LOG=GdbConnection,ReplayTimeline` and put the log here.

Those negative breakpoint numbers are internal breakpoints inserted by gdb. In this case the `next` command might have placed a breakpoint in the wrong place for some reason.

It looks like there was a library mapped there at some point: ``` [GdbConnection] raw request m7f74079ca0b0,1 [GdbConnection] gdb requests memory (addr=0x7f74079ca0b0, len=1) [GdbConnection] write_flush: '$f3#99' ``` but later on...