Kyle Huey

This is essentially the same problem as #2842, the interfering branch is 64 bytes *before* the patched syscall instruction, but our heuristics only look for interfering branches after the patched...

Hmm, so it does. It doesn't appear you made the decoder any smarter. In #2842 I gave up because instructions of the form mov [%rsi/%rdi/%r14/%r15], 0xXX(%rsp) will trigger our heuristic...

Though it appears fine on Firefox startup (the number of PATCH_SYSCALL events is the same before and after that change), so maybe my concern in #2842 was overblown.

I would expect that to be a duplicate of #2694. If you can pack and upload a trace I can verify whether or not the tracee is using RDRAND.

`Unsupported instruction at 0x7f534449603f (opcode rdrand)` Can you replay the trace, `hbreak *0x7f534449603f` in gdb. continue, and get a backtrace at that instruction?

Yup, it's the same thing in systemd (which is fixed upstream at systemd/systemd#17115)

What assembly does gcc generate for that loop? The `REP` prefixes are tricky to get right, it's possible you found another bug in our handling of them.

Ok, given that, I think it's more likely it's related to the size of the stack frame.

I can reproduce this.

Unfortunately I haven't made much progress here. The only interesting thing I've noticed is that one of the writes to the watchpoint comes from a syscall result (specifically a `read`...