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

21–30 of 56 posts

Re: Writing a debugger from scratch: Breakpoints

#21

Post by junon »

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…

Tree sitter also has a bunch of deficiencies that don't make it ideal for a number of usecases, or sort of act bizarrely in some edge cases. Just evaluate tools like this cautiously, of course. But I like what it's done for the ecosystem as a whole!

Re: Writing a debugger from scratch: Breakpoints

#22

Post by a1o »

junon wrote: post #21
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…

Tree sitter also has a bunch of deficiencies that don't make it ideal for a number of usecases, or sort of act bizarrely in some edge cases. Just evaluate tools like this cautiously, of course. But I like what it's done for the ecosystem as a whole!

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

Re: Writing a debugger from scratch: Breakpoints

#24

Post by a1o »

emmanueloga_ wrote: post #5
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...

Besides breakpoints, any ideas on inspecting the value of a variable in each step, figuring out what variables are in scope, for the case of an interpreter?

Re: Writing a debugger from scratch: Breakpoints

#26

Post by jamra »

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…

The part that makes tree-sitter useful for this kind of thing is the error recovery. It's hard to do error recovery correctly. Tree-sitter gives you the ability to continue parsing your code which makes it useful for authoring tools.

Re: Writing a debugger from scratch: Breakpoints

#27

Post by jamra »

a1o wrote: post #22
junon wrote: post #21

Earlier quoted context omitted.

Tree sitter also has a bunch of deficiencies that don't make it ideal for a number of usecases, or sort of act bizarrely in some edge cases. Just evaluate tools like this cautiously, of course. But I like what it's done for the ecosystem as a whole!

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?

Re: Writing a debugger from scratch: Breakpoints

#29

Post by whartung »

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 attached it to another process which, just so happens to be another instance of the debugger.

As with all things, while doing this they encountered bugs in the debugger that, well, needed to be debugged.

He said there was a certain epiphany when they realized, because of the multi process nature of OS/2, that they could debug the debugger debugging the debugger.

I would imagine this took a bit of focus. Turn away for a moment and probably really messes with your head.

Re: Writing a debugger from scratch: Breakpoints

#30

Post by meepmorp »

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…

It's bugs all the way down.
Post reply on HN