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

51–56 of 56 posts

Re: Writing a debugger from scratch: Breakpoints

#51

Post by Veserv »

hinoki wrote: post #50
i_don_t_know wrote: post #12

Earlier quoted context omitted.

I believe when you resume the debugger, you can tell the process/thread to single-step over one instruction. So it's something like this: 1. Overwrite instruction with int 3. 2. When you hit the breakpoint, restore the original instruction. 3. Single-step over the original instruction by changing the thread's EFlags (Intel). 4. Restore the breakpoint with int 3. 5. Resume normally.

Wouldn’t that race against any other thread in the process? I guess you could stop all threads when you hit the breakpoint and start them again after you restore the breakpoint, but the synchronisation of that would be really tricky too.

Yes. And yes that is one of the ways to solve it.

You could also do something like have a clean mapping table (i.e. the code with no breakpoints installed) that you install for just the thread doing the step. You then revert back to the normal mapping table with the breakpoint after the step. As you are only modifying the executable section, as long as you are not using self-modifying code, there should be no data inconsistency with having a multiple copys of the executable transiently.

Re: Writing a debugger from scratch: Breakpoints

#52

Post by emmanueloga_ »

a1o wrote: post #24
emmanueloga_ wrote: post #5

Earlier quoted context omitted.

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?

I’m guessing you’ll have to work with the scopes in the resolver:

https://github.com/munificent/craftinginterpreters/blob/mast...

Re: Writing a debugger from scratch: Breakpoints

#53

Post by a1o »

jamra wrote: post #49
a1o wrote: post #36

Earlier quoted context omitted.

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 th…

It looks like a bug in the grammar. I’ll bookmark this and see if I can make time for it later. Probably won’t be able to. I recently build a grammar from scratch so I’m okay at tree sitter

Oh, but if you do find time I would be externally grateful! :) The Tree Sitter generated parser is amazing for being super fast and also for being able to tolerate partially written code. This working would mean a lot for the AGS community.

Re: Writing a debugger from scratch: Breakpoints

#54

Post by a1o »

emmanueloga_ wrote: post #52
a1o wrote: post #24

Earlier quoted context omitted.

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?

I’m guessing you’ll have to work with the scopes in the resolver: https://github.com/munificent/craftinginterpreters/blob/mast...

Ooh, thanks for this! :)

Re: Writing a debugger from scratch: Breakpoints

#55

Post by emmanueloga_ »

SebastienWae wrote: post #32
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/

The last book is an example of a book that is really about debugging, not about debugger implementation. This is the case for most books you will find with a title matching /.debug./.

Debugger knowledge seems to be scattered across the internet and language implementations. Also I never found a language implementation book that talks about how to make the implementation friendlier/compatible with writing a debugger.

Post reply on HN