Live data from Hacker News

A cross-platform debugger for Go

blog.mailgun.com

1–10 of 65 posts

Re: A cross-platform debugger for Go

#2
This demonstrates the power of Go generators. We're seeing what are typically language features such as generics and debugging being implemented before runtime using code generation. The result is more functionality without an overall increase in runtime size or decrease in runtime performance.

It's unusual and it's opinionated, but it works.

Re: A cross-platform debugger for Go

#4
post #3

There's a more, er... traditional, debugger for Golang in the works: https://github.com/derekparker/delve

> When I started this project in January, gdb failed on every program I tried it on. delve didn’t work on OS X, and print-statement-debugging was too slow and limited. What's a developer to do? Make my own debugger, of course.

It seems like he tried to use delve and it wasn't portable at the time. Sure he could have worked on making delve portable instead, but he probably learned a lot more poking around the internals himself.

Re: A cross-platform debugger for Go

#6
post #2

This demonstrates the power of Go generators. We're seeing what are typically language features such as generics and debugging being implemented before runtime using code generation. The result is more functionality without an overall increase in runtime size or decrease in runtime performance. It's unusual and it's opinionated, but it works.

To be fair, this does increase runtime size and decrease performance, but that's a necessary cost that comes with the debugging capability

Re: A cross-platform debugger for Go

#7
post #2

This demonstrates the power of Go generators. We're seeing what are typically language features such as generics and debugging being implemented before runtime using code generation. The result is more functionality without an overall increase in runtime size or decrease in runtime performance. It's unusual and it's opinionated, but it works.

> This demonstrates the power of Go generators. We're seeing what are typically language features such as generics and debugging being implemented before runtime using code generation. The result is more functionality without an increase in runtime size or a decrease in performance.

Monomorphization is a bog-standard implementation technique for generics. It's not at all unusual.

Re: A cross-platform debugger for Go

#8
While I totally applaud this effort, how does it not lie? It inserts code into the actual source claiming it is on a line in the original file, but it is in a different line in the compiled version. That seems like it could be a problem at some point, and despite the serious utility in this, I'm not 100% convinced it is the right tool for the job.

Re: A cross-platform debugger for Go

#9

While I totally applaud this effort, how does it not lie? It inserts code into the actual source claiming it is on a line in the original file, but it is in a different line in the compiled version. That seems like it could be a problem at some point, and despite the serious utility in this, I'm not 100% convinced it is the right tool for the job.

Author here. I agree that this could cause surprises. Are there specific cases you have in mind?

Two cases I have thought of are stack traces and logging that inspects the stack. In the former case, if you get a stack trace while debugging it will not mean much because the lines do not match those of your code. In the latter case, logging statements may print the wrong things if they depend on being called a certain number of stack frames below user code. glog does this, for example[1]. I don't have solutions to either case yet, but I have some ideas of how to start. I think the utility the tool provides is well worth those two issues, and I'm hopeful that both can be fixed.

[1] https://github.com/golang/glog/blob/master/glog.go#L536

Re: A cross-platform debugger for Go

#10

While I totally applaud this effort, how does it not lie? It inserts code into the actual source claiming it is on a line in the original file, but it is in a different line in the compiled version. That seems like it could be a problem at some point, and despite the serious utility in this, I'm not 100% convinced it is the right tool for the job.

Go has special comments for that: "//line filename:line"
Post reply on HN