1. 02 Nov, 2019 2 commits
  2. 08 Oct, 2019 2 commits
  3. 06 Oct, 2019 2 commits
  4. 21 Aug, 2019 1 commit
  5. 15 Aug, 2019 4 commits
  6. 13 Aug, 2019 2 commits
  7. 01 Aug, 2019 1 commit
  8. 31 Jul, 2019 2 commits
  9. 30 Jul, 2019 2 commits
  10. 27 Jul, 2019 1 commit
  11. 26 Jul, 2019 2 commits
  12. 24 Jul, 2019 4 commits
  13. 23 Jul, 2019 1 commit
  14. 21 Jul, 2019 3 commits
  15. 20 Jul, 2019 5 commits
    • jD91mZM2's avatar
      WIP(ptrace): Only use non-signal stack when using a default handler · 6a3825d4
      jD91mZM2 authored
      This is a curious problem and it's really hard to solve it in a way
      that doesn't feel hacky. On one hand, of course you want to be able to
      modify and intercept what happens when you use a signal, right? On the
      other hand, changes made to the context (especially singlestepping)
      while a signal is handled (such as `SIGSTOP`) are not preserved since
      the stack is restored after the signal handler was invoked.
      
      I think what we have in this change makes sense anyway, as we don't
      really want users modifying registers and other data in the default
      signal behavior that occurs **in kernel mode**. Also trying to use
      `PTRACE_SINGLESTEP` will set the singlestep flag only if in a
      user-mode signal handler, else it will set it on the instruction after
      the signal handling, which I guess makes sense since it can't affect
      the kernel-mode code that runs the default handler.
      
      I don't know. Help. Pls.
      6a3825d4
    • jD91mZM2's avatar
      Fix sigaction Undefind Behavior · 8695ecd8
      jD91mZM2 authored
      Rust does not allow a `fn`-pointer to be null. This fixes that, while
      luckily doing it in a way that leaves system calls
      backwards-compatible :)
      8695ecd8
    • jD91mZM2's avatar
      be867ae5
    • jD91mZM2's avatar
      3d442424
    • jD91mZM2's avatar
  16. 19 Jul, 2019 6 commits