commit | 35a6c5423d0dd69c061d5b479af9863a6b4fbeb1 | [log] [tgz] |
---|---|---|
author | Derek Bruening <bruening@google.com> | Fri Oct 06 06:34:31 2017 |
committer | GitHub <noreply@github.com> | Fri Oct 06 06:34:31 2017 |
tree | 188e0575427b491f5c7ebcfb0bf4cd0d65fa9883 | |
parent | 28c4f6fb4bb1f75f28144b78ecf2fef8c06ccea3 [diff] |
i#2659 syscall restart: switch to using SA_RESTART (#2660) Changes the strategy for handling interrupted syscalls to use SA_RESTART, which adds easy handling of interruptions of auto-restart syscalls in native code, such as during attach or in client C code. This also simplifies auto-restart of app syscalls, as we now have foolproof identification of auto-restart situations (before our syscall-number-based check was inaccurate) and the kernel has restored the clobbered register value for us. That eliminates the TLS store we were doing on ARM and the decode on x86. For fragment-inlined syscalls, we don't need to do anything anymore: we deliver the signal immediately and the kernel has already set up the proper resumption state. For gencode syscalls, for sane post-syscall handling, we leverage i#1145's auto-restart emulation and undo what the kernel did. This lets us go back to dispatch for a clean sequence of events. Updates synch and translation checks for post-syscall to also account for syscall-restart locations. For sysenter, this change means we now see threads at the int 0x80 restart point whose fall-through is our vsyscall hook. To avoid interpreting our own hook we map that PC to our displaced code, and mapping back in dr_fragment_app_pc(). Fixes a race between going native and unhooking the vsyscall (to avoid takeover problems) by redirecting threads at vsyscall or the int 0x80 restart to our own gencode. Adds a test of a client making a blocking auto-restart syscall to ensure it is not terminated with EINTR. This was not simple to arrange in a non-racy manner and required adding a new feature of immediately delivering a signal that arrives in DR or client code where the receiving thread is at a safe point (because if we delay, the test cannot ensure the signal was received). Fixes #2659
DynamoRIO is a runtime code manipulation system that supports code transformations on any part of a program, while it executes. DynamoRIO exports an interface for building dynamic tools for a wide variety of uses: program analysis and understanding, profiling, instrumentation, optimization, translation, etc. Unlike many dynamic tool systems, DynamoRIO is not limited to insertion of callouts/trampolines and allows arbitrary modifications to application instructions via a powerful IA-32/AMD64/ARM/AArch64 instruction manipulation library. DynamoRIO provides efficient, transparent, and comprehensive manipulation of unmodified applications running on stock operating systems (Windows, Linux, or Android) and commodity IA-32, AMD64, ARM, and AArch64 hardware. Mac OSX support is in progress.
Tools built on DynamoRIO include:
DynamoRIO‘s powerful API abstracts away the details of the underlying infrastructure and allows the tool builder to concentrate on analyzing or modifying the application’s runtime code stream. API documentation is included in the release package and can also be browsed online. Slides from our past tutorials are also available.
DynamoRIO is available free of charge as a binary package for both Windows and Linux. DynamoRIO's source code is available under a BSD license.
Use the discussion list to ask questions.
To report a bug, use the issue tracker.
See also the DynamoRIO home page: http://dynamorio.org/