2016-03-01 15:57:46 -07:00
|
|
|
// Copyright 2012 The Go Authors. All rights reserved.
|
2012-09-24 18:06:32 -06:00
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
2014-08-12 18:04:45 -06:00
|
|
|
#include "textflag.h"
|
2014-09-12 05:29:19 -06:00
|
|
|
#include "funcdata.h"
|
2013-08-12 11:25:36 -06:00
|
|
|
|
2013-02-22 13:23:57 -07:00
|
|
|
// makeFuncStub is the code half of the function returned by MakeFunc.
|
2013-03-21 14:59:16 -06:00
|
|
|
// See the comment on the declaration of makeFuncStub in makefunc.go
|
2012-09-24 18:06:32 -06:00
|
|
|
// for more details.
|
2014-09-12 05:29:19 -06:00
|
|
|
// No arg size here; runtime pulls arg map out of the func value.
|
runtime, cmd/gc, cmd/ld: ignore method wrappers in recover
Bug #1:
Issue 5406 identified an interesting case:
defer iface.M()
may end up calling a wrapper that copies an indirect receiver
from the iface value and then calls the real M method. That's
two calls down, not just one, and so recover() == nil always
in the real M method, even during a panic.
[For the purposes of this entire discussion, a wrapper's
implementation is a function containing an ordinary call, not
the optimized tail call form that is somtimes possible. The
tail call does not create a second frame, so it is already
handled correctly.]
Fix this bug by introducing g->panicwrap, which counts the
number of bytes on current stack segment that are due to
wrapper calls that should not count against the recover
check. All wrapper functions must now adjust g->panicwrap up
on entry and back down on exit. This adds slightly to their
expense; on the x86 it is a single instruction at entry and
exit; on the ARM it is three. However, the alternative is to
make a call to recover depend on being able to walk the stack,
which I very much want to avoid. We have enough problems
walking the stack for garbage collection and profiling.
Also, if performance is critical in a specific case, it is already
faster to use a pointer receiver and avoid this kind of wrapper
entirely.
Bug #2:
The old code, which did not consider the possibility of two
calls, already contained a check to see if the call had split
its stack and so the panic-created segment was one behind the
current segment. In the wrapper case, both of the two calls
might split their stacks, so the panic-created segment can be
two behind the current segment.
Fix this by propagating the Stktop.panic flag forward during
stack splits instead of looking backward during recover.
Fixes #5406.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13367052
2013-09-12 12:00:16 -06:00
|
|
|
TEXT ·makeFuncStub(SB),(NOSPLIT|WRAPPER),$16
|
2014-09-12 05:29:19 -06:00
|
|
|
NO_LOCAL_POINTERS
|
2013-02-22 13:23:57 -07:00
|
|
|
MOVQ DX, 0(SP)
|
2013-03-22 10:57:55 -06:00
|
|
|
LEAQ argframe+0(FP), CX
|
2013-02-22 13:23:57 -07:00
|
|
|
MOVQ CX, 8(SP)
|
2012-09-24 18:06:32 -06:00
|
|
|
CALL ·callReflect(SB)
|
|
|
|
|
RET
|
2013-03-21 14:59:16 -06:00
|
|
|
|
|
|
|
|
// methodValueCall is the code half of the function returned by makeMethodValue.
|
|
|
|
|
// See the comment on the declaration of methodValueCall in makefunc.go
|
|
|
|
|
// for more details.
|
2014-09-12 05:29:19 -06:00
|
|
|
// No arg size here; runtime pulls arg map out of the func value.
|
runtime, cmd/gc, cmd/ld: ignore method wrappers in recover
Bug #1:
Issue 5406 identified an interesting case:
defer iface.M()
may end up calling a wrapper that copies an indirect receiver
from the iface value and then calls the real M method. That's
two calls down, not just one, and so recover() == nil always
in the real M method, even during a panic.
[For the purposes of this entire discussion, a wrapper's
implementation is a function containing an ordinary call, not
the optimized tail call form that is somtimes possible. The
tail call does not create a second frame, so it is already
handled correctly.]
Fix this bug by introducing g->panicwrap, which counts the
number of bytes on current stack segment that are due to
wrapper calls that should not count against the recover
check. All wrapper functions must now adjust g->panicwrap up
on entry and back down on exit. This adds slightly to their
expense; on the x86 it is a single instruction at entry and
exit; on the ARM it is three. However, the alternative is to
make a call to recover depend on being able to walk the stack,
which I very much want to avoid. We have enough problems
walking the stack for garbage collection and profiling.
Also, if performance is critical in a specific case, it is already
faster to use a pointer receiver and avoid this kind of wrapper
entirely.
Bug #2:
The old code, which did not consider the possibility of two
calls, already contained a check to see if the call had split
its stack and so the panic-created segment was one behind the
current segment. In the wrapper case, both of the two calls
might split their stacks, so the panic-created segment can be
two behind the current segment.
Fix this by propagating the Stktop.panic flag forward during
stack splits instead of looking backward during recover.
Fixes #5406.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13367052
2013-09-12 12:00:16 -06:00
|
|
|
TEXT ·methodValueCall(SB),(NOSPLIT|WRAPPER),$16
|
2014-09-12 05:29:19 -06:00
|
|
|
NO_LOCAL_POINTERS
|
2013-03-21 14:59:16 -06:00
|
|
|
MOVQ DX, 0(SP)
|
2013-03-22 10:57:55 -06:00
|
|
|
LEAQ argframe+0(FP), CX
|
2013-03-21 14:59:16 -06:00
|
|
|
MOVQ CX, 8(SP)
|
|
|
|
|
CALL ·callMethod(SB)
|
|
|
|
|
RET
|
