• Refactor fail

    In the last post we implemented a state machine to manage breakpoints in rusty_trap. We also added support for hitting a single breakpoint multiple times. Now, I want to start adding support for multiple distinct breakpoints.

    One way to approach adding a new feature is to refactor to make the code easily accept the new feature. That’s what I set out to do today, but it didn’t go the way I planned.

  • Debuger state machine in Rust

    In this post I’ll continue with the development of the rusty_trap debugger by developing a formal state machine to improve the way breakpoint handling is implemented. This post parallels the debugger state machine in C post.

  • rusty_trap: refactoring ptrace code

    This post is an exercise in refactoring Rust code. I’ll be clearning up code written a few posts ago for rusty_trap. In the process I’ll explore a few topics that are new to me: operator overloading and other traits.

  • Handling multiple breakpoints in Trap

    In the last post we implemented a state machine to manage breakpoints in Trap. In that post we were left with a small TODO list:

    • Pay attention to what the warnings are telling us
    • Write a test that sets more than one breakpoint.

    We will address these remaining issues, and more, in this post.

  • Implementing breakpoints in Rust

    In this post I will continue working on writing a debugger crate in Rust called rusty_trap. We’ll be implementing support for breakpoints by writing INT 3 instructions into the inferior. I’ll also explore building up a proper API for the debugger crate. This will all mirror the work done implementing breakpoints in C.


Want more? See all posts or subscribe via RSS