qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-14 13:30:30 -07:00
Code Releases Activity

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

Browse Source 
««« 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
This commit is contained in:
Russ Cox 2014-02-27 22:43:47 -05:00
parent 495b91430f
commit 0d2f5c0e3b
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
src/pkg/runtime/sys_x86.c
View File

@ -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");
}