After last thursday’s presentations I asked Gargi Sharma, to walk me through the debugger that she wrote for go.  It was super cool and I just going to review the highlights.

First off how does the debugger work….  Well you pass in the binary of the program you want to debug as a binary.  Then you generate a symbol table, which associates an address of memory with a command. This is important because in Gargi’s code when you set a breakpoint you replace the command where you want to break with an INTERRUPT CODE (think ctrl-z) BRILLIANT!  You also need a data structure to map the line numbers to the commands in the symbol table.

But the main takeaway… debuggers (or this one at least) works by inserting an INTERRUPT – []byte{0xCC}.

You could theoretically debug any binary this way, but this code generates a sym table for go, so you can only use it to debug go. If you wanted to debug another language you would need to use the symtable for that language.

Also this code uses some unix based tools, so Gargi runs it in docker on her osx. If you wanted to run it natively on osx or windows you would have to replace these tools such as ptrace.  Ptrace allows the debugger to inspect the code of the process it is debugging.

Gargi also introduced me to ELF. ELF is a format for binary and object codes etc.  It lets you search for a section of code when you initialize your debugger. For example in line 156 of Gargi’s  debugger.go She looks for .text. I assume she knows to do this because of the ELF format. If I am wrong let me know.

Anyway, I am super grateful that Gargi took the time to walk me through this. Debuggers are something I have used for a long time but they were mysterious. Now I know the secret -CTRL-Z!  I forked Gargi’s code and may do some sort of musical debugger experiment. But I highly recommend going over to her github and checking it out. It is only 226 lines.