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

31–40 of 56 posts

Re: Writing a debugger from scratch: Breakpoints

#31

Post by cbsks »

whartung wrote: post #29

I’ll share this anecdote told by a friend of mine. He was on a team building a Modula-2 compiler for OS/2, and his group was working on the debugger. At some point a debugger becomes feature complete enough that you can use the debugger to ... debug the debugger. But this was OS/2 which has true multiple processes (unlike it’s contemporary Windows 3.1). So you could, naturally, run the debugger in one process and att…

I worked at a company that made JTAG probes. When you wanted to debug the firmware on the probe you’d attach another probe to it. And if you encountered a bug while debugging that probe, then you’d attach another probe…

Re: Writing a debugger from scratch: Breakpoints

#32

Post by SebastienWae »

matt3210 wrote: post #28

Does anyone know a similar article using c/c++? Interesting concept.

Yes, the "Writing a Linux Debugger" series in C++. https://blog.tartanllama.xyz/writing-a-linux-debugger-setup/

And more generally there is "The Debugging Book" in python. https://www.debuggingbook.org/

Re: Writing a debugger from scratch: Breakpoints

#33

Post by timmisiak »

whartung wrote: post #29

I’ll share this anecdote told by a friend of mine. He was on a team building a Modula-2 compiler for OS/2, and his group was working on the debugger. At some point a debugger becomes feature complete enough that you can use the debugger to ... debug the debugger. But this was OS/2 which has true multiple processes (unlike it’s contemporary Windows 3.1). So you could, naturally, run the debugger in one process and att…

I think my record when I was on the WinDbg team was 5 debuggers deep.

I honestly think one of the best parts of writing a debugger is being your own recursive customer. I think that's something you only get to do for a few things. Debuggers, languages/compilers, and operating systems. And probably a few others.

Re: Writing a debugger from scratch: Breakpoints

#34

Post by timmisiak »

ekidd wrote: post #16

This is a great series! I noticed that the author was using https://github.com/hydro-project/rust-sitter as a parser. Which is based on https://tree-sitter.github.io/tree-sitter/ . I've been hearing about Tree-sitter a lot recently, so I dug into it. Tree-sitter is a tool for generating fast, incremental parsers. In particular, the algorithm is suited towards writing "language servers" for IDEs, which re-parse code i…

Absolutely, rust sitter is fantastic. I haven't used any other parsers in Rust so I don't have much of a comparison point, but it's probably hard to get much more clear and concise, which I think really helps.

Re: Writing a debugger from scratch: Breakpoints

#35

Post by timmisiak »

hinoki wrote: post #9
ithkuil wrote: post #6

Earlier quoted context omitted.

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…

Yes, software breakpoints are difficult to get correct (the main reason why I started with hardware breakpoints). It gets more complicated with kernel debugging, where a single step (trap flag) could get pre-empted by an interrupt handler. And you can't always single-step a CPU and leave all other CPUs frozen.

Re: Writing a debugger from scratch: Breakpoints

#36

Post by a1o »

jamra wrote: post #27
a1o wrote: post #22

Earlier quoted context omitted.

I still don't know how to deal with forward declarations when using tree-sitter. :/

Because tree-sitter lexes as it parses, you may have to use an external scanner in order to deal with this kind of stuff. Where are you stuck trying to deal with forward declarations?

It's a simple parser that was originally made to be used through Atom that I would like to repurpose elsewhere

https://github.com/edmundito/tree-sitter-ags-script/issues/1

If this could be solved, we could port this AGS Script parser to the AGS Editor. Today, the parser Adventure Game Studio uses for the needs like auto-complete and it's very simple refactor like things uses a custom handmade parser built in C#. I think if we could leverage tree-sitter we could speed things up and repurpose it to build things like a LSP for AGS Script.

Re: Writing a debugger from scratch: Breakpoints

#38

Post by gpderetta »

whartung wrote: post #29

I’ll share this anecdote told by a friend of mine. He was on a team building a Modula-2 compiler for OS/2, and his group was working on the debugger. At some point a debugger becomes feature complete enough that you can use the debugger to ... debug the debugger. But this was OS/2 which has true multiple processes (unlike it’s contemporary Windows 3.1). So you could, naturally, run the debugger in one process and att…

Surely you would then attach the debugger being debugged to the original debugger to debug it and stop the recursion (and of course instantly deadlock).

Re: Writing a debugger from scratch: Breakpoints

#39

Post by robertlagrant »

timmisiak wrote: post #33
whartung wrote: post #29

I’ll share this anecdote told by a friend of mine. He was on a team building a Modula-2 compiler for OS/2, and his group was working on the debugger. At some point a debugger becomes feature complete enough that you can use the debugger to ... debug the debugger. But this was OS/2 which has true multiple processes (unlike it’s contemporary Windows 3.1). So you could, naturally, run the debugger in one process and att…

I think my record when I was on the WinDbg team was 5 debuggers deep. I honestly think one of the best parts of writing a debugger is being your own recursive customer. I think that's something you only get to do for a few things. Debuggers, languages/compilers, and operating systems. And probably a few others.

Font authors?
Post reply on HN