@mvdan May I carry on the task to work on this issue please?

It's not assigned, so you're welcome to try. Though I think @dr2chase has specific plans on how to fix it, and they're non-trivial.

Ah, plans are changing slightly, and might become simpler. I experimented with gdb-MI a little bit, and it appears that it might still be flaky (I am not 100% sure of this), plus in practice, people use Delve, not gdb, because gdb doesn't do a good job with goroutines.

And Delve isn't flaky. I have to be sure that Delve is supported on our test boxes, and then we switch to that as the default.

The fix I imagine is to enhance debug_test.go to do one of the following:

• take a step limit (either read from the file or as part of test specification)
• take an "exit" annotation in the source file, telling to quit out of the process

And then use that to write the test.

Change https://golang.org/cl/168477 mentions this issue: cmd/compile: expose ssa/debug_test step limit to bound infinite loops

It needs more than just a test; there's something buggy going on, but I won't get to it today.
Recommended attack (in CL above) is

cd src/cmd/compile/internal/ssa/testdata
GOSSAFUNC=test go build infloop.go

It loops like we should maybe notice that we are creating a one-instruction infinite loop, and throw a nop in there? I'm not sure, it depends on debugger heuristics, but it is definitely tagged as a statement.

That would make the infinite loop take longer to finish....