[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

diff --git a/src/pkg/runtime/sys_x86.c b/src/pkg/runtime/sys_x86.c
index e68ff514a224de31906107e801ea1325106f2051..0df6dfbbd3c34fd9061d54c61f2907255deab137 100644 (file)
--- 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");
 }