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

src/pkg/runtime/sys_x86.c

@@ -27,7 +27,6 @@ void
 runtime·rewindmorestack(Gobuf *gobuf)
 {
 	byte *pc;
-	Func *f;
 
 	pc = (byte*)gobuf->pc;
 	if(pc[0] == 0xe9) { // jmp 4-byte offset
@@ -38,12 +37,18 @@ runtime·rewindmorestack(Gobuf *gobuf)
 		gobuf->pc = gobuf->pc + 2 + *(int8*)(pc+1);
 		return;
 	}
-	if(pc[0] == 0xcc) { // breakpoint inserted by gdb
-		f = runtime·findfunc(gobuf->pc);
-		if(f != nil) {
-			gobuf->pc = f->entry;
-			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");