Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A cross-platform debugger for Go

blog.mailgun.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: A cross-platform debugger for Go

#31

Post by andrewchambers »

jschlatter wrote: post #23
andrewchambers wrote: post #22

How does this handle go routines? Can only one be paused at a time?

Author 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?

In a well behaved program, all theads should probably be synchronized by mutexes/channels etc, so pausing one thread, should in theory pause all related ones.

I think one is fine for now.

Re: A cross-platform debugger for Go

#32

Post by jschlatter »

sippndipp wrote: post #29

What an awesome idea to use gopherjs. Just added it to http://golangtoolbox.com/ - if you have more tools that are great please add them here.

Thanks! 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, where you can debug little Go snippets on the web. Is that something that you would find useful?

Re: A cross-platform debugger for Go

#33

Post by jschlatter »

DannyBee wrote: post #28
skybrian wrote: post #24

Earlier quoted context omitted.

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. So, when debugging is turned on, the code would return the right answers, but it wouldn't have the same performance.

"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 librar…

"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?

Re: A cross-platform debugger for Go

#34

Post by kzhahou »

pcwalton wrote: post #7
e79 wrote: 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.

source?

Re: A cross-platform debugger for Go

#36

Post by polymathist »

jschlatter wrote: post #32
sippndipp wrote: post #29

What an awesome idea to use gopherjs. Just added it to http://golangtoolbox.com/ - if you have more tools that are great please add them here.

Thanks! 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 , where you can debug little Go snippets on the web. Is that something that you would find useful?

I 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!

Re: A cross-platform debugger for Go

#38

Post by chrisseaton »

howeman wrote: post #6
e79 wrote: 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

"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_...

Re: A cross-platform debugger for Go

#39

Post by chrisseaton »

jschlatter wrote: post #33
DannyBee wrote: post #28

Earlier quoted context omitted.

"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 librar…

"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?

say you have:

    x = 1
    x = 2
    bar()
You set a breakpoint on the call to bar and examine the value of x. You would expect it to be 2, but what if the compiler had decided to move the allocation of x = 2 to after the call to bar? There's no reason why it shouldn't. You'd then see x = 1, which would confuse you.

Re: A cross-platform debugger for Go

#40

Post by DannyBee »

jschlatter wrote: post #33
DannyBee wrote: post #28

Earlier quoted context omitted.

"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 librar…

"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?

Sure, i'll stick to bugs invisible with the library, and visible without it:

If you've inserted compiler barriers it can't move code across, the compiler will no longer perform the same optimizations with and without your debug library.

Those optimizations often make bugs visible, because variables no longer have the value you expect them to at the time you expect it, etc.

Add in threads, and the problem gets worse:

http://preshing.com/20120515/memory-reordering-caught-in-the...

Look at the behavior this has with and without the barrier. It's buggy without it. With it, it's fine.

This is exactly equivalent to:

Without the debugging library, the code is clearly buggy and doesn't work in user-visible ways.

With the debugging library, if i insert a breakpoint where the current asm barrier is, it now behaves correctly 100% of the time, even though it's broken.

Post reply on HN