Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a debugger from scratch: Breakpoints

timdbg.com

Post reply on HN
Print view View original

1–10 of 56 posts

Re: Writing a debugger from scratch: Breakpoints

#4

Post by saagarjha »

danparsonson wrote: post #3

Great article, thanks - one question I couldn't see answered there is, what do you do when you want to set more than four breakpoints at once?

Use software breakpoints (which are mentioned but not described, the short story for those is you overwrite the address you care about with an illegal instruction and execution traps when it encounters that code, and then you undo it to continue).

Re: Writing a debugger from scratch: Breakpoints

#5

Post by emmanueloga_ »

zubairq wrote: post #2

Really nice read. Does anyone know any other good articles or videos about how to write a debugger?

I was asking this myself this while reading the book "Crafting Interpreters". I posted a few resources I found on an issue about implementing debuggers [1] -- although honestly I still haven't gotten down to read all of them (or to implement a debugger! :-/).

--

1: https://github.com/munificent/craftinginterpreters/issues/92...

Re: Writing a debugger from scratch: Breakpoints

#6

Post by ithkuil »

danparsonson wrote: post #3

Great article, thanks - one question I couldn't see answered there is, what do you do when you want to set more than four breakpoints at once?

You use software breakpoints.

Basically you overwrite the instruction you want to break at with a breakpoint instruction (e.g. int 3 on x86). This will cause the process to trap and the OS will then let the debugger process know about out somehow, e.g. via the SIGTRAP signal on Unix.

The debugger then replaces the int 3 opcode (which is a single byte conveniently) with the first byte of the original instruction so that the execution can continue.

Re: Writing a debugger from scratch: Breakpoints

#9

Post by hinoki »

ithkuil wrote: post #6
danparsonson wrote: post #3

Great article, thanks - one question I couldn't see answered there is, what do you do when you want to set more than four breakpoints at once?

You use software breakpoints. Basically you overwrite the instruction you want to break at with a breakpoint instruction (e.g. int 3 on x86). This will cause the process to trap and the OS will then let the debugger process know about out somehow, e.g. via the SIGTRAP signal on Unix. The debugger then replaces the int 3 opcode (which is a single byte conveniently) with the first byte of the original instruction so th…

If you revert the int 3 to the original instruction’s byte, when do you put it back? The breakpoint could still be active.

In a trivial example, the breaking instruction could be a jump to itself, which you’d expect to immediately break into the debugger again.

I thought the debugger had to emulate the instruction instead, but it’s not like I’ve ever implemented one…

Post reply on HN