[release-branch.go1.2] runtime: if traceback sees a breakpoint, don't change the PC

««« CL 49580044 / 38cd458b1dfe
runtime: if traceback sees a breakpoint, don't change the PC

Changing the PC confuses gdb, because execution does not
continue where gdb expects it.  Not changing the PC has the
potential to confuse a stack dump, but when running under gdb
it seems better to confuse a stack dump than to confuse gdb.

Fixes #6776.

LGTM=rsc
R=golang-codereviews, dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/49580044
»»»

LGTM=r
R=golang-codereviews, r
CC=golang-dev
https://golang.org/cl/69800043

1 files changed, 13 insertions, 0 deletions

diff --git a/src/pkg/runtime/sys_x86.c b/src/pkg/runtime/sys_x86.c
index e68ff514a2..0df6dfbbd3 100644
--- a/src/pkg/runtime/sys_x86.c
+++ b/src/pkg/runtime/sys_x86.c
@@ -37,6 +37,19 @@ runtime·rewindmorestack(Gobuf *gobuf)
 		gobuf->pc = gobuf->pc + 2 + *(int8*)(pc+1);
 		return;
 	}
+ 	if(pc[0] == 0xcc) {
+ 		// This is a breakpoint inserted by gdb.  We could use
+ 		// runtime·findfunc to find the function.  But if we
+ 		// do that, then we will continue execution at the
+ 		// function entry point, and we will not hit the gdb
+ 		// breakpoint.  So for this case we don't change
+ 		// gobuf->pc, so that when we return we will execute
+ 		// the jump instruction and carry on.  This means that
+ 		// stack unwinding may not work entirely correctly
+ 		// (http://golang.org/issue/5723) but the user is
+ 		// running under gdb anyhow.
+ 		return;
+	}
 	runtime·printf("runtime: pc=%p %x %x %x %x %x\n", pc, pc[0], pc[1], pc[2], pc[3], pc[4]);
 	runtime·throw("runtime: misuse of rewindmorestack");
 }