21–30 of 65 posts
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 ...)
How does this handle go routines? Can only one be paused at a time?
What 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 ...)
So, when debugging is turned on, the code would return the right answers, but it wouldn't have the same performance.
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…
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?
What 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 ...)
What 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 ...)
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.
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)
Earlier quoted context omitted.
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?
I'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?
>>> 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
[1] https://github.com/mailgun/godebug/blob/5c173f56b398bc13fd41... [2] https://github.com/mailgun/godebug/blob/5c173f56b398bc13fd41...
EDIT: formatting