IRC channel logs

<ekaitz>I have a question for the C hackers here

<ekaitz>why gdb is unable to `record` my binary?

<ekaitz>> Process record and replay target doesn't support syscall number 334

<muurkha>it sounds like it's unable to record your binary because it doesn't support syscall number 334

<muurkha>record and replay needs to understand every syscall that happens during recording

<muurkha>and, more annoyingly, every ioctl

<muurkha>that's because if you do a syscall it doesn't understand, that syscall can provide some input to your program by modifying its memory in some random place that gdb can't guess

<muurkha>and without recording that input, it can't reproduce its behavior on replay

<muurkha>I tried this to find out what 334 might be: locate syscall.h | xargs grep 334

<muurkha>it suggested: /usr/include/x86_64-linux-musl/bits/syscall.h:#define SYS_rseq 334

<muurkha>I've never heard of rseq

<muurkha>apparently it's https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2 according to https://lore.kernel.org/lkml/075db450-dc23-ff79-e1ce-1a8aad69f3e5@efficios.com/T/

<ekaitz>that's weird muurkha

<ekaitz>hmm

<ekaitz>thanks a lot for the explanation, though, now I understand

<ekaitz>if I record in a smaller piece of code I can manage to avoid the rseq?

<ekaitz>i did but 318 appeared :)

<ekaitz>haha

<muurkha>are you sure it's really using rseq?

IRC channel logs

2023-08-03.log