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

61–65 of 65 posts

Re: A cross-platform debugger for Go

#61

Post by ghodss »

DannyBee wrote: post #44
jschlatter wrote: post #41

Earlier quoted context omitted.

Thanks for the concrete example. The transformed source code that would get compiled for this example looks like: scope.Declare("x", &x) godebug.Line(ctx, scope, 3) x = 1 godebug.Line(ctx, scope, 4) x = 2 godebug.Line(ctx, scope, 5) bar() The value of x is visible to all of the godebug.Line calls, so the compiler should know that it can't move x = 2 to after the call to bar.

Right, but now you have the opposite problem. Let's say that before the compiler could move x=2 after bar (let's assume bar does not touch x). Now, in your world, it can't. So before, you would have seen x=1 in the call to bar, and now when you use the debug library, you will see x=2.

But it's not really material, because bar doesn't touch x (and if it did, this problem wouldn't exist to begin with).

In other words, it might be a bit strange and cause a slight detour in your quest to discover the cause of a bug, but it wouldn't actually change any behavior or cause any issues.

Re: A cross-platform debugger for Go

#62

Post by Jweb_Guru »

kzhahou wrote: post #47
pcwalton wrote: post #42

Earlier quoted context omitted.

Just off the top of my head, C++, .NET (via a JIT), Rust, D, MLton, and (I think) Swift all do it.

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

The 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.

Re: A cross-platform debugger for Go

#63

Post by [deleted] »

ghodss wrote: post #61
DannyBee wrote: post #44

Earlier quoted context omitted.

Right, but now you have the opposite problem. Let's say that before the compiler could move x=2 after bar (let's assume bar does not touch x). Now, in your world, it can't. So before, you would have seen x=1 in the call to bar, and now when you use the debug library, you will see x=2.

But it's not really material, because bar doesn't touch x (and if it did, this problem wouldn't exist to begin with). In other words, it might be a bit strange and cause a slight detour in your quest to discover the cause of a bug, but it wouldn't actually change any behavior or cause any issues.

[deleted]

Re: A cross-platform debugger for Go

#64

Post by DannyBee »

ghodss wrote: post #61
DannyBee wrote: post #44

Earlier quoted context omitted.

Right, but now you have the opposite problem. Let's say that before the compiler could move x=2 after bar (let's assume bar does not touch x). Now, in your world, it can't. So before, you would have seen x=1 in the call to bar, and now when you use the debug library, you will see x=2.

But it's not really material, because bar doesn't touch x (and if it did, this problem wouldn't exist to begin with). In other words, it might be a bit strange and cause a slight detour in your quest to discover the cause of a bug, but it wouldn't actually change any behavior or cause any issues.

Your argument is essentially: The barriers you insert, even if they block optimization, will never block optimization in a way that changes behavior. This is demonstrably false, since you are, among other things, taking the address of a variable, which means escape analysis won't do things to it, etc.

You can argue "The behavior it changes doesn't matter". As i've shown, 1. it does in a threaded environment (like, you know, go) 2. It depends on whether your code is buggy or not.

IT's certainly true that it never, on it's own, causes bugs. But as i've shown, it can make bugs appear to come or go.

If you don't think that will ever happen, i don't know what to tell you, other than "It has happened in literally every compiler that has ever had barriers like this".

Without any evidence why Go should be different here, i don't see why go will be different here.

Post reply on HN