#syscalls #debugging #instrumentation #trace #strace

nightly no-std pai

Process Analyzer and Instrumenter

11 releases

0.1.11 Mar 9, 2024
0.1.10 Mar 4, 2024
0.1.7 Feb 13, 2024
0.1.5 Jan 31, 2024

#4 in #strace

Download history 38/week @ 2024-01-26 48/week @ 2024-02-09 56/week @ 2024-02-16 18/week @ 2024-02-23 364/week @ 2024-03-01 202/week @ 2024-03-08 18/week @ 2024-03-15 3/week @ 2024-03-22 13/week @ 2024-03-29 2/week @ 2024-04-05

509 downloads per month
Used in 2 crates

Custom license

380KB
11K SLoC

pai

Process Analyzer and Instrumenter

Recommended way to include the crate, even though API is not expected to be stable until version 0.2.0, is:

pai = { version = "0.1", features = ["syscalls"] }

The feature syscalls is only needed if you want to resolve the arguments of system calls. So if you want to resolve the system call number to a name, an argument to strings, etc.

There are some example of use under examples/ more information will be written when the API is more stable.

Standalone tools using pai

Compilation

A regular build for native can be compiled with:

cargo build --all-features

Cross-compilation

The recommended way to cross-compile is to use cross

This is setup in Makefile.toml, so you can build for all desired targets with:

cargo make build i686-unknown-linux-gnu x86_64-unknown-linux-gnu ...

Build output from cross will sometimes interfere with build output from cargo so all cross builds will go to directory output/, leaving target/ for regular cargo commands.

Builds will then work as expected, but most test-targets will fail because the testing method used doesn't support ptrace.

To run cross-architecture tests correctly see testing.md

Targets tested

We don't want to test all cross-combination of builds, but try to test all platforms supported and all architectures supported.

  • platforms: GNU, Android, Musl
  • architectures: x86_64, x86, Aarch64, Aarch32

The Makefile.toml target fulltest is executed before new versions are published.

Known issues

  • PTRACE_SINGLESTEP is not working correctly on Aarch32 or Riscv64. This is a deliberate limitation of Aarch32, I'm unsure if the same is the case for Riscv64.
    • As a workaround, we insert a new breakpoint after the instruction to simulate a single-step.
    • This workaround is obviously flawed as the next instruction may be a branch. This is currently not detected and the step would then be missed completely.
    • This bug may appear even if you don't use single-stepping since single-stepping is used internally in those cases we need to redo something on the next instruction, like re-inserting a breakppoint.

Known cross-compilation issues

Dependencies

~7–17MB
~237K SLoC