11 ms·
A cross-platform debugger for Go
- e79 11y agoThis 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.
- howeman 11y agoTo be fair, this does increase runtime size and decrease performance, but that's a necessary cost that comes with the debugging capability
- chrisseaton 11y ago"that's a necessary cost that comes with the debugging capability" I'm doing some research that shows this isn't the case. You can have a system where enabling the debugger has zero impact on runtime performance, via dynamic deoptimization. http://www.lifl.fr/dyla14/papers/dyla14-3-Debugging_at_Full_Speed.pdf http://www.lifl.fr/dyla14/papers/dyla14-3-Debugging_at_Full_...
- pcwalton 11y ago> 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.
- kzhahou 11y agosource?
- pcwalton 11y agoJust off the top of my head, C++, .NET (via a JIT), Rust, D, MLton, and (I think) Swift all do it.
- kzhahou 11y agoI was hoping for some article or wikipedia entry that would tie your comment with the parent's comment, and with the original article. Monomorphization is, to my understanding, taking a polymorphic function and instantiating it to the specific type requested. This is done at compile time. Now, the tool in this article interleaves debugging code with original source code. So the connection is... both monomorphization of generics/templates and this tool operate by emitting source code prior to compilation?
- Jweb_Guru 11y agoThe original comment was about how both debugging and generics are being implemented with code generation before runtime in Go and described this as "unusual." The response was that this precise technique is how generics are implemented in many languages already; in fact, CFront (the original C++ compiler) was entirely implemented as code generation on top of C. The response specifically discussed generics, not debugging, so I'm not sure why you thought it was talking about debugging.
- IndianAstronaut 11y agoWhat is the difference between the generators in Python vs Go?
- chrj 11y agoThey're not the same thing. This is about code generators (https://blog.golang.org/generate https://blog.golang.org/generate) while in Python context you're most likely talking about iteration.
- troym 11y agoThere's a more, er... traditional, debugger for Golang in the works: https://github.com/derekparker/delve https://github.com/derekparker/delve
- TkTech 11y ago> 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.
- ihuman 11y agoDoes Delve only allow you set breakpoints while running the program in Delve?
- cmelbye 11y agoYes: https://github.com/derekparker/delve#breakpoints https://github.com/derekparker/delve#breakpoints
- tyho 11y agoComparing the Linux and OSX instructions is fun: https://github.com/derekparker/delve#building https://github.com/derekparker/delve#building
- sunnyps 11y agoIf I remember correctly I had to follow the same instructions for installing gdb too :/
- autoreleasepool 11y agoReally? I just did brew install gdb
- lighthawk 11y agoWhile 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.
- jschlatter 11y agoAuthor 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 https://github.com/golang/glog/blob/master/glog.go#L536
- deleted 11y ago[deleted]
- jschlatter 11y ago> Another is that you may inadvertently corrupt or change the behavior of the code in an unintentional way if you modify it incorrectly I'm concerned about this, too. One of my next high priorities for godebug is to download many open source projects and search for behavior differences caused by the debugger. I would also like to generate new programs and test them as well. > But, you get the easy 80% with this for sure. I'm just prodding you to work on the other 20%. I will. I'm excited about the project and want to make it as useful as I can.
- andrewchambers 11y agoA compiler transforms source code. It doesn't have access to all programs either, yet we trust them most of the time.
- dvirsky 11y agoThis looks really great. When I saw how Go does coverage testing using the same approach I felt that the code generation approach would work for a debugger. I'm glad someone did it - and from the few moments of playing with it it seems to be working great. I'm adding this to my toolkit for sure.
- djhworld 11y agoThis is really cool, thanks.
- tlrobinson 11y agoI wrote a similar instrumenting debugger for JavaScript awhile back, but haven't maintained it: https://github.com/tlrobinson/xebug https://github.com/tlrobinson/xebug At one point even I implemented the V8 debugger protocol so you could use the Web Inspector, and an HTTP proxy that would automatically instrument JavaScript files (using synchronous XMLHttpRequests to block execution...), but I don't think I ever posted that code :(
- caioariede 11y agoIt would be nice to have something like this for Rust.
- DannyBee 11y agoWhat do you do for inlining + code movement, where functions become interleaved (as do lines)? In particular, after inlining, how are you guaranteeing statements from a given function don't get moved before the inlined enterfunction call (and similarly with lines) Or do you not expect it to ever be able to report right answers for optimized programs? (which is a valid way to live life, of course, but ...)
- skybrian 11y agoSince it's modifying the source before compiling it, I expect that the compiler will conclude that most optimizations can't be applied when they cross breakpoint boundaries. So, when debugging is turned on, the code would return the right answers, but it wouldn't have the same performance.
- DannyBee 11y ago"Since it's modifying the source before compiling it, I expect that the compiler will conclude that most optimizations can't be applied when they cross breakpoint boundaries." While true, this depends on the compiler knowing this is a magical breakpoint barrier it can't move things across. The compiler has no idea this is a magical barrier unless something has told it it's a magical barrier. Looking at godebug library, i don't see this being the case, it looks like it translates into an atomic store and an atomic load to some variables, and then a function call, which the compiler is definitely not going to see as a "nothing can move across" barrier. (Also, having the debugging library alter the semantics of the program is 100% guaranteed to lead to bugs that are not visible when using the library, etc)
- jschlatter 11y ago"Also, having the debugging library alter the semantics of the program is 100% guaranteed to lead to bugs that are not visible when using the library, etc" Can you give an example of the kind of bug you expect to see?
- 11y ago
- andrewchambers 11y agoHow does this handle go routines? Can only one be paused at a time?
- jschlatter 11y agoAuthor here. Yes, only one goroutine is paused at a time. I'm planning to add commands to show and jump between goroutines. Still sketching those out, though. Do you think it would be helpful to have multiple goroutines paused by the debugger at once?
- dvirsky 11y agoI'd like to be able to completely pause all goroutines and slowly analyze the state of each one. You can probably just add some mutex or waitgroup to your line() method and just lock it when a goroutine pauses, no?
- jschlatter 11y agoYeah, that should be relatively easy to do. We would just skip the "am I the goroutine under the debugger" check here [1] and add some kind of channel communication here [2]. The hardest thing is probably just the UI. How should that functionality work? I'm imagining something like this: >>> pause all All goroutines paused >>> show goroutines 1: foo.go:16 2: foo.go:24 3. bar.go:10 [current] >>> next -> // some code from goroutine 3 >>> goroutine 2 Now tracing goroutine 2. Current location: /* Code listing from goroutine 2's current location */ >>> next -> // some code from goroutine 2 Is this the kind of interface you were imagining? [1] https://github.com/mailgun/godebug/blob/5c173f56b398bc13fd4175bc828cb1b6bfa9e47e/lib/debug.go#L293 https://github.com/mailgun/godebug/blob/5c173f56b398bc13fd41... [2] https://github.com/mailgun/godebug/blob/5c173f56b398bc13fd4175bc828cb1b6bfa9e47e/lib/debug.go#L300 https://github.com/mailgun/godebug/blob/5c173f56b398bc13fd41... EDIT: formatting
- dvirsky 11y agoYep, something like gdb's threads interface.
- sippndipp 11y agoWhat an awesome idea to use gopherjs. Just added it to http://golangtoolbox.com/ http://golangtoolbox.com/ - if you have more tools that are great please add them here.
- jschlatter 11y agoThanks! gopherjs is a really great project. This was my first time using it and I was impressed. I've considered putting it up as a permanent playground like http://play.golang.org http://play.golang.org, where you can debug little Go snippets on the web. Is that something that you would find useful?
- polymathist 11y agoI agree with you about gopherjs being an awesome project. And I would love to see a playground-like debugger that you could run directly in your browser for quick debugging!
- Firstmate 11y agoHi, not relevant to the topic. I visited your site, specifically "Homepage > Show all categories > Crypto" (http://golangtoolbox.com/categories/crypto http://golangtoolbox.com/categories/crypto) and was met with: "template: views/layout:views/categories/show:1:301: executing "views/categories/show::main" at <.CurrentUser.Id>: nil pointer evaluating interface {}.Id" Happens when viewing any category. Looks like a useful site though.
- housel 11y agoNorman Ramsey and David R. Hanson implemented this sort of compiler-assisted debugging for C back in 1992, in a debugger called ldb: http://www.cs.tufts.edu/~nr/pubs/retargetable-abstract.html http://www.cs.tufts.edu/~nr/pubs/retargetable-abstract.html
- Rapzid 11y agoCurious.. I used debugging in LiteIDE a while back and it seemed to work well. Anyone else using it successfully?
- jschlatter 11y agoLiteIDE was probably using gdb as a backend. gdb is not a very reliable debugger as of the last few Go releases. Here's a demo of a common failure mode of gdb on Go: occasionally running the entire program when you try to take a single step https://youtu.be/qo4RAPxCTa0?t=351 https://youtu.be/qo4RAPxCTa0?t=351 This failure mode is a large part of why I decided to write godebug.
- shurcooL 11y agoI love the in-browser demo of this Go program via GopherJS. So easy to try and become familiar. Well done!
- eosrei 11y agoJeremy Schlatter, godebug creator, did an interesting talk introducing the project March 18th at GoSF. The slides are available here: https://github.com/jeremyschlatter/godebug-talk https://github.com/jeremyschlatter/godebug-talk