|
|
Subscribe / Log in / New account

Restartable sequences in glibc

Restartable sequences in glibc

Posted Jan 31, 2022 20:04 UTC (Mon) by mjw (subscriber, #16740)
In reply to: Restartable sequences in glibc by roc
Parent article: Restartable sequences in glibc

Did you have to do anything special for rr?
Do you have a pointer to your patch?

For valgrind we opted for now to simply return ENOSYS for rseq after consulting with the glibc hackers to confirm this causes glibc to simply skip the rseq setup when running under valgrind (as if running on a kernel that doesn't implement rseq).

https://bugs.kde.org/show_bug.cgi?id=405377

A real implementation is somewhat tricky if you might have instrumented the restartable sequence. DynamoRIO lists some issues and their current "run twice" approach https://dynamorio.org/page_rseq.html

to post comments

Restartable sequences in glibc

Posted Jan 31, 2022 23:54 UTC (Mon) by zx2c4 (subscriber, #82519) [Link]

https://github.com/rr-debugger/rr/commit/64f0d4ef83bd36ee...

Restartable sequences in glibc

Posted Feb 1, 2022 6:53 UTC (Tue) by roc (subscriber, #30627) [Link] (1 responses)

rr generally doesn't instrument code. Also, we run code on a single core and control scheduling. It is therefore pretty easy to for us to emulate rseq completely. We don't pass the syscall through, instead when rr performs a context switch or signal delivery, we emulate an rsync abort ourselves if necessary.

Restartable sequences in glibc

Posted Feb 1, 2022 6:54 UTC (Tue) by roc (subscriber, #30627) [Link]

Oh and rr also pins tracees to a single core (usually) so there are never any CPU migrations.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds