2015-06-12 19:49:23 +00:00
|
|
|
package proc
|
2014-12-05 22:17:10 +00:00
|
|
|
|
|
|
|
import (
|
2020-01-21 17:11:20 +00:00
|
|
|
"bytes"
|
2021-07-08 15:47:53 +00:00
|
|
|
"debug/dwarf"
|
2016-01-20 20:22:39 +00:00
|
|
|
"errors"
|
2014-12-05 22:17:10 +00:00
|
|
|
"fmt"
|
2016-01-12 08:01:42 +00:00
|
|
|
"go/ast"
|
|
|
|
"go/token"
|
2020-03-23 17:57:01 +00:00
|
|
|
"path/filepath"
|
2020-06-05 17:29:28 +00:00
|
|
|
"strings"
|
2020-02-11 01:31:54 +00:00
|
|
|
|
2020-03-25 11:37:15 +00:00
|
|
|
"github.com/go-delve/delve/pkg/astutil"
|
2020-03-23 17:57:01 +00:00
|
|
|
"github.com/go-delve/delve/pkg/dwarf/reader"
|
2014-12-05 22:17:10 +00:00
|
|
|
)
|
|
|
|
|
2020-03-09 09:47:56 +00:00
|
|
|
const maxSkipAutogeneratedWrappers = 5 // maximum recursion depth for skipAutogeneratedWrappers
|
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
// ErrNoSourceForPC is returned when the given address
|
|
|
|
// does not correspond with a source file location.
|
|
|
|
type ErrNoSourceForPC struct {
|
|
|
|
pc uint64
|
2018-06-21 11:07:37 +00:00
|
|
|
}
|
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
func (err *ErrNoSourceForPC) Error() string {
|
|
|
|
return fmt.Sprintf("no source for PC %#x", err.pc)
|
2015-01-01 13:23:55 +00:00
|
|
|
}
|
|
|
|
|
2016-01-10 08:57:52 +00:00
|
|
|
// Next continues execution until the next source line.
|
2020-03-24 16:16:58 +00:00
|
|
|
func (dbp *Target) Next() (err error) {
|
2018-06-21 11:07:37 +00:00
|
|
|
if _, err := dbp.Valid(); err != nil {
|
|
|
|
return err
|
2016-01-30 06:23:14 +00:00
|
|
|
}
|
2021-07-21 15:24:19 +00:00
|
|
|
if dbp.Breakpoints().HasSteppingBreakpoints() {
|
2017-09-25 06:29:13 +00:00
|
|
|
return fmt.Errorf("next while nexting")
|
2015-04-25 02:56:57 +00:00
|
|
|
}
|
|
|
|
|
proc: support inlining
Go 1.10 added inlined calls to debug_info, this commit adds support
for DW_TAG_inlined_call to delve, both for stack traces (where
inlined calls will appear as normal stack frames) and to correct
the behavior of next, step and stepout.
The calls to Next and Frame of stackIterator continue to work
unchanged and only return real stack frames, after reading each line
appendInlinedCalls is called to unpacked all the inlined calls that
involve the current PC.
The fake stack frames produced by appendInlinedCalls are
distinguished from real stack frames by having the Inlined attribute
set to true. Also their Current and Call locations are treated
differently. The Call location will be changed to represent the
position inside the inlined call, while the Current location will
always reference the real stack frame. This is done because:
* next, step and stepout need to access the debug_info entry of
the real function they are stepping through
* we are already manipulating Call in different ways while Current
is just what we read from the call stack
The strategy remains mostly the same, we disassemble the function
and we set a breakpoint on each instruction corresponding to a
different file:line. The function in question will be the one
corresponding to the first real (i.e. non-inlined) stack frame.
* If the current function contains inlined calls, 'next' will not
set any breakpoints on instructions that belong to inlined calls. We
do not do this for 'step'.
* If we are inside an inlined call that makes other inlined
functions, 'next' will not set any breakpoints that belong to
inlined calls that are children of the current inlined call.
* If the current function is inlined the breakpoint on the return
address won't be set, because inlined frames don't have a return
address.
* The code we use for stepout doesn't work at all if we are inside
an inlined call, instead we call 'next' but instruct it to remove
all PCs belonging to the current inlined call.
2017-11-13 15:54:08 +00:00
|
|
|
if err = next(dbp, false, false); err != nil {
|
2021-07-21 15:24:19 +00:00
|
|
|
dbp.ClearSteppingBreakpoints()
|
2017-07-24 08:58:12 +00:00
|
|
|
return
|
2015-08-22 03:13:54 +00:00
|
|
|
}
|
|
|
|
|
2020-03-24 16:16:58 +00:00
|
|
|
return dbp.Continue()
|
2017-02-22 08:35:21 +00:00
|
|
|
}
|
|
|
|
|
2016-01-10 08:57:52 +00:00
|
|
|
// Continue continues execution of the debugged
|
|
|
|
// process. It will continue until it hits a breakpoint
|
|
|
|
// or is otherwise stopped.
|
2020-03-24 16:16:58 +00:00
|
|
|
func (dbp *Target) Continue() error {
|
2018-06-21 11:07:37 +00:00
|
|
|
if _, err := dbp.Valid(); err != nil {
|
|
|
|
return err
|
2017-07-26 22:57:47 +00:00
|
|
|
}
|
2018-05-11 12:51:15 +00:00
|
|
|
for _, thread := range dbp.ThreadList() {
|
2020-12-10 16:57:50 +00:00
|
|
|
thread.Common().CallReturn = false
|
2018-05-11 12:51:15 +00:00
|
|
|
thread.Common().returnValues = nil
|
|
|
|
}
|
2018-02-09 19:42:45 +00:00
|
|
|
dbp.CheckAndClearManualStopRequest()
|
2018-03-07 10:14:34 +00:00
|
|
|
defer func() {
|
|
|
|
// Make sure we clear internal breakpoints if we simultaneously receive a
|
|
|
|
// manual stop request and hit a breakpoint.
|
|
|
|
if dbp.CheckAndClearManualStopRequest() {
|
2020-03-10 19:27:38 +00:00
|
|
|
dbp.StopReason = StopManual
|
2021-07-21 15:24:19 +00:00
|
|
|
dbp.ClearSteppingBreakpoints()
|
2018-03-07 10:14:34 +00:00
|
|
|
}
|
|
|
|
}()
|
2015-11-18 09:07:08 +00:00
|
|
|
for {
|
2018-02-09 19:42:45 +00:00
|
|
|
if dbp.CheckAndClearManualStopRequest() {
|
2020-03-10 19:27:38 +00:00
|
|
|
dbp.StopReason = StopManual
|
2021-07-21 15:24:19 +00:00
|
|
|
dbp.ClearSteppingBreakpoints()
|
2017-07-07 23:29:37 +00:00
|
|
|
return nil
|
|
|
|
}
|
2021-07-02 16:37:55 +00:00
|
|
|
dbp.ClearCaches()
|
2021-08-09 17:16:24 +00:00
|
|
|
trapthread, stopReason, contOnceErr := dbp.proc.ContinueOnce()
|
2020-03-10 19:27:38 +00:00
|
|
|
dbp.StopReason = stopReason
|
2021-08-09 17:16:24 +00:00
|
|
|
|
|
|
|
threads := dbp.ThreadList()
|
|
|
|
for _, thread := range threads {
|
|
|
|
if thread.Breakpoint().Breakpoint != nil {
|
|
|
|
thread.Breakpoint().Breakpoint.checkCondition(dbp, thread, thread.Breakpoint())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if contOnceErr != nil {
|
2020-06-11 18:46:00 +00:00
|
|
|
// Attempt to refresh status of current thread/current goroutine, see
|
|
|
|
// Issue #2078.
|
|
|
|
// Errors are ignored because depending on why ContinueOnce failed this
|
|
|
|
// might very well not work.
|
|
|
|
if valid, _ := dbp.Valid(); valid {
|
|
|
|
if trapthread != nil {
|
|
|
|
_ = dbp.SwitchThread(trapthread.ThreadID())
|
|
|
|
} else if curth := dbp.CurrentThread(); curth != nil {
|
|
|
|
dbp.selectedGoroutine, _ = GetG(curth)
|
|
|
|
}
|
|
|
|
}
|
2021-08-09 17:16:24 +00:00
|
|
|
if pe, ok := contOnceErr.(ErrProcessExited); ok {
|
2021-06-22 11:35:13 +00:00
|
|
|
dbp.exitStatus = pe.Status
|
|
|
|
}
|
2021-08-09 17:16:24 +00:00
|
|
|
return contOnceErr
|
2015-11-18 09:07:08 +00:00
|
|
|
}
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
if dbp.StopReason == StopLaunched {
|
2021-07-21 15:24:19 +00:00
|
|
|
dbp.ClearSteppingBreakpoints()
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
}
|
2015-11-18 09:07:08 +00:00
|
|
|
|
2020-04-22 14:34:48 +00:00
|
|
|
callInjectionDone, callErr := callInjectionProtocol(dbp, threads)
|
|
|
|
// callErr check delayed until after pickCurrentThread, which must always
|
|
|
|
// happen, otherwise the debugger could be left in an inconsistent
|
|
|
|
// state.
|
2019-06-30 17:44:30 +00:00
|
|
|
|
2017-02-22 08:35:21 +00:00
|
|
|
if err := pickCurrentThread(dbp, trapthread, threads); err != nil {
|
2015-07-10 19:48:45 +00:00
|
|
|
return err
|
|
|
|
}
|
2016-01-16 08:13:15 +00:00
|
|
|
|
2020-04-22 14:34:48 +00:00
|
|
|
if callErr != nil {
|
|
|
|
return callErr
|
|
|
|
}
|
|
|
|
|
2017-02-22 08:35:21 +00:00
|
|
|
curthread := dbp.CurrentThread()
|
2017-09-25 06:29:13 +00:00
|
|
|
curbp := curthread.Breakpoint()
|
2017-02-22 08:35:21 +00:00
|
|
|
|
2015-11-24 21:48:28 +00:00
|
|
|
switch {
|
2017-09-25 06:29:13 +00:00
|
|
|
case curbp.Breakpoint == nil:
|
2018-05-04 17:31:45 +00:00
|
|
|
// runtime.Breakpoint, manual stop or debugCallV1-related stop
|
|
|
|
recorded, _ := dbp.Recorded()
|
|
|
|
if recorded {
|
|
|
|
return conditionErrors(threads)
|
|
|
|
}
|
|
|
|
|
|
|
|
loc, err := curthread.Location()
|
|
|
|
if err != nil || loc.Fn == nil {
|
|
|
|
return conditionErrors(threads)
|
|
|
|
}
|
2019-06-30 17:44:30 +00:00
|
|
|
g, _ := GetG(curthread)
|
2020-01-21 17:11:20 +00:00
|
|
|
arch := dbp.BinInfo().Arch
|
2018-05-04 17:31:45 +00:00
|
|
|
|
|
|
|
switch {
|
|
|
|
case loc.Fn.Name == "runtime.breakpoint":
|
2019-11-08 04:50:41 +00:00
|
|
|
// In linux-arm64, PtraceSingleStep seems cannot step over BRK instruction
|
|
|
|
// (linux-arm64 feature or kernel bug maybe).
|
2020-01-21 17:11:20 +00:00
|
|
|
if !arch.BreakInstrMovesPC() {
|
2021-03-04 18:28:28 +00:00
|
|
|
setPC(curthread, loc.PC+uint64(arch.BreakpointSize()))
|
2019-11-08 04:50:41 +00:00
|
|
|
}
|
2017-02-07 21:07:18 +00:00
|
|
|
// Single-step current thread until we exit runtime.breakpoint and
|
|
|
|
// runtime.Breakpoint.
|
|
|
|
// On go < 1.8 it was sufficient to single-step twice on go1.8 a change
|
|
|
|
// to the compiler requires 4 steps.
|
2018-05-04 17:31:45 +00:00
|
|
|
if err := stepInstructionOut(dbp, curthread, "runtime.breakpoint", "runtime.Breakpoint"); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-03-10 19:27:38 +00:00
|
|
|
dbp.StopReason = StopHardcodedBreakpoint
|
2018-05-04 17:31:45 +00:00
|
|
|
return conditionErrors(threads)
|
2020-01-21 20:41:24 +00:00
|
|
|
case g == nil || dbp.fncallForG[g.ID] == nil:
|
2020-01-21 17:11:20 +00:00
|
|
|
// a hardcoded breakpoint somewhere else in the code (probably cgo), or manual stop in cgo
|
|
|
|
if !arch.BreakInstrMovesPC() {
|
|
|
|
bpsize := arch.BreakpointSize()
|
|
|
|
bp := make([]byte, bpsize)
|
2020-11-09 19:28:40 +00:00
|
|
|
_, err = dbp.Memory().ReadMemory(bp, loc.PC)
|
2020-01-21 17:11:20 +00:00
|
|
|
if bytes.Equal(bp, arch.BreakpointInstruction()) {
|
2021-03-04 18:28:28 +00:00
|
|
|
setPC(curthread, loc.PC+uint64(bpsize))
|
2020-01-21 17:11:20 +00:00
|
|
|
}
|
|
|
|
}
|
2018-05-04 17:31:45 +00:00
|
|
|
return conditionErrors(threads)
|
2015-03-01 04:03:26 +00:00
|
|
|
}
|
2021-07-21 15:24:19 +00:00
|
|
|
case curbp.Active && curbp.Stepping:
|
|
|
|
if curbp.SteppingInto {
|
2016-07-26 13:34:31 +00:00
|
|
|
// See description of proc.(*Process).next for the meaning of StepBreakpoints
|
2017-02-22 08:35:21 +00:00
|
|
|
if err := conditionErrors(threads); err != nil {
|
2016-07-26 13:34:31 +00:00
|
|
|
return err
|
|
|
|
}
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
if dbp.GetDirection() == Forward {
|
2020-07-28 16:19:51 +00:00
|
|
|
text, err := disassembleCurrentInstruction(dbp, curthread, 0)
|
2020-06-05 17:29:28 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
var fn *Function
|
|
|
|
if loc, _ := curthread.Location(); loc != nil {
|
|
|
|
fn = loc.Fn
|
|
|
|
}
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
// here we either set a breakpoint into the destination of the CALL
|
|
|
|
// instruction or we determined that the called function is hidden,
|
|
|
|
// either way we need to resume execution
|
2020-06-05 17:29:28 +00:00
|
|
|
if err = setStepIntoBreakpoint(dbp, fn, text, sameGoroutineCondition(dbp.SelectedGoroutine())); err != nil {
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
} else {
|
2021-07-21 15:24:19 +00:00
|
|
|
if err := dbp.ClearSteppingBreakpoints(); err != nil {
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
return err
|
|
|
|
}
|
2020-03-24 16:16:58 +00:00
|
|
|
return dbp.StepInstruction()
|
2016-07-26 13:34:31 +00:00
|
|
|
}
|
2021-07-21 15:24:19 +00:00
|
|
|
} else {
|
2021-07-02 16:37:55 +00:00
|
|
|
curthread.Common().returnValues = curbp.Breakpoint.returnInfo.Collect(dbp, curthread)
|
2021-07-21 15:24:19 +00:00
|
|
|
if err := dbp.ClearSteppingBreakpoints(); err != nil {
|
2016-07-26 13:34:31 +00:00
|
|
|
return err
|
|
|
|
}
|
2020-03-10 19:27:38 +00:00
|
|
|
dbp.StopReason = StopNextFinished
|
2017-02-22 08:35:21 +00:00
|
|
|
return conditionErrors(threads)
|
2016-01-12 08:01:42 +00:00
|
|
|
}
|
2017-09-25 06:29:13 +00:00
|
|
|
case curbp.Active:
|
2021-08-09 17:16:24 +00:00
|
|
|
onNextGoroutine, err := onNextGoroutine(dbp, curthread, dbp.Breakpoints())
|
2016-01-12 08:01:42 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
2016-01-16 08:13:15 +00:00
|
|
|
}
|
2016-01-12 08:01:42 +00:00
|
|
|
if onNextGoroutine {
|
2021-07-21 15:24:19 +00:00
|
|
|
err := dbp.ClearSteppingBreakpoints()
|
2016-01-12 08:01:42 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
2017-09-20 12:19:59 +00:00
|
|
|
if curbp.Name == UnrecoveredPanic {
|
2021-07-21 15:24:19 +00:00
|
|
|
dbp.ClearSteppingBreakpoints()
|
2017-09-20 12:19:59 +00:00
|
|
|
}
|
2020-03-10 19:27:38 +00:00
|
|
|
dbp.StopReason = StopBreakpoint
|
2021-05-06 17:33:56 +00:00
|
|
|
if curbp.Breakpoint.WatchType != 0 {
|
|
|
|
dbp.StopReason = StopWatchpoint
|
|
|
|
}
|
2017-02-22 08:35:21 +00:00
|
|
|
return conditionErrors(threads)
|
2015-11-24 21:48:28 +00:00
|
|
|
default:
|
|
|
|
// not a manual stop, not on runtime.Breakpoint, not on a breakpoint, just repeat
|
2015-03-01 04:03:26 +00:00
|
|
|
}
|
2019-06-30 17:44:30 +00:00
|
|
|
if callInjectionDone {
|
|
|
|
// a call injection was finished, don't let a breakpoint with a failed
|
|
|
|
// condition or a step breakpoint shadow this.
|
2020-03-10 19:27:38 +00:00
|
|
|
dbp.StopReason = StopCallReturned
|
2019-06-30 17:44:30 +00:00
|
|
|
return conditionErrors(threads)
|
|
|
|
}
|
2015-11-24 21:48:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-21 07:50:38 +00:00
|
|
|
func conditionErrors(threads []Thread) error {
|
2016-01-12 08:01:42 +00:00
|
|
|
var condErr error
|
2017-02-22 08:35:21 +00:00
|
|
|
for _, th := range threads {
|
2017-09-25 06:29:13 +00:00
|
|
|
if bp := th.Breakpoint(); bp.Breakpoint != nil && bp.CondError != nil {
|
2016-01-12 08:01:42 +00:00
|
|
|
if condErr == nil {
|
2017-09-25 06:29:13 +00:00
|
|
|
condErr = bp.CondError
|
2016-01-12 08:01:42 +00:00
|
|
|
} else {
|
|
|
|
return fmt.Errorf("multiple errors evaluating conditions")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return condErr
|
|
|
|
}
|
|
|
|
|
2017-02-08 00:23:47 +00:00
|
|
|
// pick a new dbp.currentThread, with the following priority:
|
2016-09-30 06:35:29 +00:00
|
|
|
// - a thread with onTriggeredInternalBreakpoint() == true
|
2015-11-24 21:48:28 +00:00
|
|
|
// - a thread with onTriggeredBreakpoint() == true (prioritizing trapthread)
|
|
|
|
// - trapthread
|
2020-03-10 19:27:38 +00:00
|
|
|
func pickCurrentThread(dbp *Target, trapthread Thread, threads []Thread) error {
|
2017-02-22 08:35:21 +00:00
|
|
|
for _, th := range threads {
|
2021-07-21 15:24:19 +00:00
|
|
|
if bp := th.Breakpoint(); bp.Active && bp.Stepping {
|
2017-02-22 08:35:21 +00:00
|
|
|
return dbp.SwitchThread(th.ThreadID())
|
2015-11-24 21:48:28 +00:00
|
|
|
}
|
|
|
|
}
|
2017-09-25 06:29:13 +00:00
|
|
|
if bp := trapthread.Breakpoint(); bp.Active {
|
2017-02-22 08:35:21 +00:00
|
|
|
return dbp.SwitchThread(trapthread.ThreadID())
|
2015-11-24 21:48:28 +00:00
|
|
|
}
|
2017-02-22 08:35:21 +00:00
|
|
|
for _, th := range threads {
|
2017-09-25 06:29:13 +00:00
|
|
|
if bp := th.Breakpoint(); bp.Active {
|
2017-02-22 08:35:21 +00:00
|
|
|
return dbp.SwitchThread(th.ThreadID())
|
2015-11-24 21:48:28 +00:00
|
|
|
}
|
|
|
|
}
|
2017-02-22 08:35:21 +00:00
|
|
|
return dbp.SwitchThread(trapthread.ThreadID())
|
2014-12-05 22:17:10 +00:00
|
|
|
}
|
|
|
|
|
2020-07-28 16:19:51 +00:00
|
|
|
func disassembleCurrentInstruction(p Process, thread Thread, off int64) ([]AsmInstruction, error) {
|
2020-05-13 18:56:50 +00:00
|
|
|
regs, err := thread.Registers()
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2020-07-28 16:19:51 +00:00
|
|
|
pc := regs.PC() + uint64(off)
|
2020-11-09 19:28:40 +00:00
|
|
|
return disassemble(p.Memory(), regs, p.Breakpoints(), p.BinInfo(), pc, pc+uint64(p.BinInfo().Arch.MaxInstructionLength()), true)
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
}
|
|
|
|
|
2018-05-04 17:31:45 +00:00
|
|
|
// stepInstructionOut repeatedly calls StepInstruction until the current
|
|
|
|
// function is neither fnname1 or fnname2.
|
|
|
|
// This function is used to step out of runtime.Breakpoint as well as
|
|
|
|
// runtime.debugCallV1.
|
2020-03-10 19:27:38 +00:00
|
|
|
func stepInstructionOut(dbp *Target, curthread Thread, fnname1, fnname2 string) error {
|
2021-07-02 16:37:55 +00:00
|
|
|
defer dbp.ClearCaches()
|
2018-05-04 17:31:45 +00:00
|
|
|
for {
|
|
|
|
if err := curthread.StepInstruction(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
loc, err := curthread.Location()
|
2021-07-08 15:47:53 +00:00
|
|
|
var locFnName string
|
|
|
|
if loc.Fn != nil {
|
|
|
|
locFnName = loc.Fn.Name
|
|
|
|
// Calls to runtime.Breakpoint are inlined in some versions of Go when
|
|
|
|
// inlining is enabled. Here we attempt to resolve any inlining.
|
|
|
|
dwarfTree, _ := loc.Fn.cu.image.getDwarfTree(loc.Fn.offset)
|
|
|
|
if dwarfTree != nil {
|
|
|
|
inlstack := reader.InlineStack(dwarfTree, loc.PC)
|
|
|
|
if len(inlstack) > 0 {
|
|
|
|
if locFnName2, ok := inlstack[0].Val(dwarf.AttrName).(string); ok {
|
|
|
|
locFnName = locFnName2
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if err != nil || loc.Fn == nil || (locFnName != fnname1 && locFnName != fnname2) {
|
2019-06-30 17:44:30 +00:00
|
|
|
g, _ := GetG(curthread)
|
|
|
|
selg := dbp.SelectedGoroutine()
|
|
|
|
if g != nil && selg != nil && g.ID == selg.ID {
|
|
|
|
selg.CurrentLoc = *loc
|
2018-05-04 17:31:45 +00:00
|
|
|
}
|
2019-08-12 22:11:19 +00:00
|
|
|
return curthread.SetCurrentBreakpoint(true)
|
2018-05-04 17:31:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-24 05:25:46 +00:00
|
|
|
// Step will continue until another source line is reached.
|
|
|
|
// Will step into functions.
|
2020-03-24 16:16:58 +00:00
|
|
|
func (dbp *Target) Step() (err error) {
|
2018-06-21 11:07:37 +00:00
|
|
|
if _, err := dbp.Valid(); err != nil {
|
|
|
|
return err
|
2016-01-24 05:25:46 +00:00
|
|
|
}
|
2021-07-21 15:24:19 +00:00
|
|
|
if dbp.Breakpoints().HasSteppingBreakpoints() {
|
2017-09-25 06:29:13 +00:00
|
|
|
return fmt.Errorf("next while nexting")
|
2016-04-24 23:20:02 +00:00
|
|
|
}
|
2016-04-13 13:25:23 +00:00
|
|
|
|
proc: support inlining
Go 1.10 added inlined calls to debug_info, this commit adds support
for DW_TAG_inlined_call to delve, both for stack traces (where
inlined calls will appear as normal stack frames) and to correct
the behavior of next, step and stepout.
The calls to Next and Frame of stackIterator continue to work
unchanged and only return real stack frames, after reading each line
appendInlinedCalls is called to unpacked all the inlined calls that
involve the current PC.
The fake stack frames produced by appendInlinedCalls are
distinguished from real stack frames by having the Inlined attribute
set to true. Also their Current and Call locations are treated
differently. The Call location will be changed to represent the
position inside the inlined call, while the Current location will
always reference the real stack frame. This is done because:
* next, step and stepout need to access the debug_info entry of
the real function they are stepping through
* we are already manipulating Call in different ways while Current
is just what we read from the call stack
The strategy remains mostly the same, we disassemble the function
and we set a breakpoint on each instruction corresponding to a
different file:line. The function in question will be the one
corresponding to the first real (i.e. non-inlined) stack frame.
* If the current function contains inlined calls, 'next' will not
set any breakpoints on instructions that belong to inlined calls. We
do not do this for 'step'.
* If we are inside an inlined call that makes other inlined
functions, 'next' will not set any breakpoints that belong to
inlined calls that are children of the current inlined call.
* If the current function is inlined the breakpoint on the return
address won't be set, because inlined frames don't have a return
address.
* The code we use for stepout doesn't work at all if we are inside
an inlined call, instead we call 'next' but instruct it to remove
all PCs belonging to the current inlined call.
2017-11-13 15:54:08 +00:00
|
|
|
if err = next(dbp, true, false); err != nil {
|
2021-07-21 15:24:19 +00:00
|
|
|
_ = dbp.ClearSteppingBreakpoints()
|
2020-11-09 19:28:40 +00:00
|
|
|
return err
|
2016-02-12 07:43:22 +00:00
|
|
|
}
|
2016-07-26 13:34:31 +00:00
|
|
|
|
2021-07-21 15:24:19 +00:00
|
|
|
if bpstate := dbp.CurrentThread().Breakpoint(); bpstate.Breakpoint != nil && bpstate.Active && bpstate.SteppingInto && dbp.GetDirection() == Backward {
|
|
|
|
dbp.ClearSteppingBreakpoints()
|
2020-03-24 16:16:58 +00:00
|
|
|
return dbp.StepInstruction()
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
}
|
|
|
|
|
2020-03-24 16:16:58 +00:00
|
|
|
return dbp.Continue()
|
2016-02-12 07:43:22 +00:00
|
|
|
}
|
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
// sameGoroutineCondition returns an expression that evaluates to true when
|
2017-04-21 06:55:53 +00:00
|
|
|
// the current goroutine is g.
|
2020-03-23 17:57:01 +00:00
|
|
|
func sameGoroutineCondition(g *G) ast.Expr {
|
2016-04-11 11:50:01 +00:00
|
|
|
if g == nil {
|
|
|
|
return nil
|
|
|
|
}
|
2020-03-25 11:37:15 +00:00
|
|
|
return astutil.Eql(astutil.Sel(astutil.PkgVar("runtime", "curg"), "goid"), astutil.Int(int64(g.ID)))
|
2017-05-16 18:23:33 +00:00
|
|
|
}
|
|
|
|
|
2020-03-25 11:37:15 +00:00
|
|
|
func frameoffCondition(frame *Stackframe) ast.Expr {
|
|
|
|
return astutil.Eql(astutil.PkgVar("runtime", "frameoff"), astutil.Int(frame.FrameOffset()))
|
2017-05-16 18:23:33 +00:00
|
|
|
}
|
|
|
|
|
2016-04-14 09:58:59 +00:00
|
|
|
// StepOut will continue until the current goroutine exits the
|
|
|
|
// function currently being executed or a deferred function is executed
|
2020-03-24 16:16:58 +00:00
|
|
|
func (dbp *Target) StepOut() error {
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
backward := dbp.GetDirection() == Backward
|
2018-06-21 11:07:37 +00:00
|
|
|
if _, err := dbp.Valid(); err != nil {
|
|
|
|
return err
|
2017-07-26 22:57:47 +00:00
|
|
|
}
|
2021-07-21 15:24:19 +00:00
|
|
|
if dbp.Breakpoints().HasSteppingBreakpoints() {
|
2018-05-04 17:31:45 +00:00
|
|
|
return fmt.Errorf("next while nexting")
|
|
|
|
}
|
|
|
|
|
2017-02-22 08:35:21 +00:00
|
|
|
selg := dbp.SelectedGoroutine()
|
|
|
|
curthread := dbp.CurrentThread()
|
2016-04-14 09:58:59 +00:00
|
|
|
|
2017-05-16 18:23:33 +00:00
|
|
|
topframe, retframe, err := topframe(selg, curthread)
|
2016-04-14 09:58:59 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
proc: support inlining
Go 1.10 added inlined calls to debug_info, this commit adds support
for DW_TAG_inlined_call to delve, both for stack traces (where
inlined calls will appear as normal stack frames) and to correct
the behavior of next, step and stepout.
The calls to Next and Frame of stackIterator continue to work
unchanged and only return real stack frames, after reading each line
appendInlinedCalls is called to unpacked all the inlined calls that
involve the current PC.
The fake stack frames produced by appendInlinedCalls are
distinguished from real stack frames by having the Inlined attribute
set to true. Also their Current and Call locations are treated
differently. The Call location will be changed to represent the
position inside the inlined call, while the Current location will
always reference the real stack frame. This is done because:
* next, step and stepout need to access the debug_info entry of
the real function they are stepping through
* we are already manipulating Call in different ways while Current
is just what we read from the call stack
The strategy remains mostly the same, we disassemble the function
and we set a breakpoint on each instruction corresponding to a
different file:line. The function in question will be the one
corresponding to the first real (i.e. non-inlined) stack frame.
* If the current function contains inlined calls, 'next' will not
set any breakpoints on instructions that belong to inlined calls. We
do not do this for 'step'.
* If we are inside an inlined call that makes other inlined
functions, 'next' will not set any breakpoints that belong to
inlined calls that are children of the current inlined call.
* If the current function is inlined the breakpoint on the return
address won't be set, because inlined frames don't have a return
address.
* The code we use for stepout doesn't work at all if we are inside
an inlined call, instead we call 'next' but instruct it to remove
all PCs belonging to the current inlined call.
2017-11-13 15:54:08 +00:00
|
|
|
success := false
|
|
|
|
defer func() {
|
|
|
|
if !success {
|
2021-07-21 15:24:19 +00:00
|
|
|
dbp.ClearSteppingBreakpoints()
|
proc: support inlining
Go 1.10 added inlined calls to debug_info, this commit adds support
for DW_TAG_inlined_call to delve, both for stack traces (where
inlined calls will appear as normal stack frames) and to correct
the behavior of next, step and stepout.
The calls to Next and Frame of stackIterator continue to work
unchanged and only return real stack frames, after reading each line
appendInlinedCalls is called to unpacked all the inlined calls that
involve the current PC.
The fake stack frames produced by appendInlinedCalls are
distinguished from real stack frames by having the Inlined attribute
set to true. Also their Current and Call locations are treated
differently. The Call location will be changed to represent the
position inside the inlined call, while the Current location will
always reference the real stack frame. This is done because:
* next, step and stepout need to access the debug_info entry of
the real function they are stepping through
* we are already manipulating Call in different ways while Current
is just what we read from the call stack
The strategy remains mostly the same, we disassemble the function
and we set a breakpoint on each instruction corresponding to a
different file:line. The function in question will be the one
corresponding to the first real (i.e. non-inlined) stack frame.
* If the current function contains inlined calls, 'next' will not
set any breakpoints on instructions that belong to inlined calls. We
do not do this for 'step'.
* If we are inside an inlined call that makes other inlined
functions, 'next' will not set any breakpoints that belong to
inlined calls that are children of the current inlined call.
* If the current function is inlined the breakpoint on the return
address won't be set, because inlined frames don't have a return
address.
* The code we use for stepout doesn't work at all if we are inside
an inlined call, instead we call 'next' but instruct it to remove
all PCs belonging to the current inlined call.
2017-11-13 15:54:08 +00:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
|
|
|
|
if topframe.Inlined {
|
|
|
|
if err := next(dbp, false, true); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
success = true
|
2020-03-24 16:16:58 +00:00
|
|
|
return dbp.Continue()
|
proc: support inlining
Go 1.10 added inlined calls to debug_info, this commit adds support
for DW_TAG_inlined_call to delve, both for stack traces (where
inlined calls will appear as normal stack frames) and to correct
the behavior of next, step and stepout.
The calls to Next and Frame of stackIterator continue to work
unchanged and only return real stack frames, after reading each line
appendInlinedCalls is called to unpacked all the inlined calls that
involve the current PC.
The fake stack frames produced by appendInlinedCalls are
distinguished from real stack frames by having the Inlined attribute
set to true. Also their Current and Call locations are treated
differently. The Call location will be changed to represent the
position inside the inlined call, while the Current location will
always reference the real stack frame. This is done because:
* next, step and stepout need to access the debug_info entry of
the real function they are stepping through
* we are already manipulating Call in different ways while Current
is just what we read from the call stack
The strategy remains mostly the same, we disassemble the function
and we set a breakpoint on each instruction corresponding to a
different file:line. The function in question will be the one
corresponding to the first real (i.e. non-inlined) stack frame.
* If the current function contains inlined calls, 'next' will not
set any breakpoints on instructions that belong to inlined calls. We
do not do this for 'step'.
* If we are inside an inlined call that makes other inlined
functions, 'next' will not set any breakpoints that belong to
inlined calls that are children of the current inlined call.
* If the current function is inlined the breakpoint on the return
address won't be set, because inlined frames don't have a return
address.
* The code we use for stepout doesn't work at all if we are inside
an inlined call, instead we call 'next' but instruct it to remove
all PCs belonging to the current inlined call.
2017-11-13 15:54:08 +00:00
|
|
|
}
|
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
sameGCond := sameGoroutineCondition(selg)
|
2016-04-14 09:58:59 +00:00
|
|
|
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
if backward {
|
|
|
|
if err := stepOutReverse(dbp, topframe, retframe, sameGCond); err != nil {
|
|
|
|
return err
|
2016-04-14 09:58:59 +00:00
|
|
|
}
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
|
|
|
|
success = true
|
2020-03-24 16:16:58 +00:00
|
|
|
return dbp.Continue()
|
2016-04-14 09:58:59 +00:00
|
|
|
}
|
|
|
|
|
2020-04-10 15:49:57 +00:00
|
|
|
deferpc, err := setDeferBreakpoint(dbp, nil, topframe, sameGCond, false)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
2016-04-14 09:58:59 +00:00
|
|
|
}
|
|
|
|
|
proc: support inlining
Go 1.10 added inlined calls to debug_info, this commit adds support
for DW_TAG_inlined_call to delve, both for stack traces (where
inlined calls will appear as normal stack frames) and to correct
the behavior of next, step and stepout.
The calls to Next and Frame of stackIterator continue to work
unchanged and only return real stack frames, after reading each line
appendInlinedCalls is called to unpacked all the inlined calls that
involve the current PC.
The fake stack frames produced by appendInlinedCalls are
distinguished from real stack frames by having the Inlined attribute
set to true. Also their Current and Call locations are treated
differently. The Call location will be changed to represent the
position inside the inlined call, while the Current location will
always reference the real stack frame. This is done because:
* next, step and stepout need to access the debug_info entry of
the real function they are stepping through
* we are already manipulating Call in different ways while Current
is just what we read from the call stack
The strategy remains mostly the same, we disassemble the function
and we set a breakpoint on each instruction corresponding to a
different file:line. The function in question will be the one
corresponding to the first real (i.e. non-inlined) stack frame.
* If the current function contains inlined calls, 'next' will not
set any breakpoints on instructions that belong to inlined calls. We
do not do this for 'step'.
* If we are inside an inlined call that makes other inlined
functions, 'next' will not set any breakpoints that belong to
inlined calls that are children of the current inlined call.
* If the current function is inlined the breakpoint on the return
address won't be set, because inlined frames don't have a return
address.
* The code we use for stepout doesn't work at all if we are inside
an inlined call, instead we call 'next' but instruct it to remove
all PCs belonging to the current inlined call.
2017-11-13 15:54:08 +00:00
|
|
|
if topframe.Ret == 0 && deferpc == 0 {
|
|
|
|
return errors.New("nothing to stepout to")
|
|
|
|
}
|
|
|
|
|
2016-04-14 09:58:59 +00:00
|
|
|
if topframe.Ret != 0 {
|
2020-03-09 09:47:56 +00:00
|
|
|
topframe, retframe := skipAutogeneratedWrappersOut(selg, curthread, &topframe, &retframe)
|
2020-03-25 11:37:15 +00:00
|
|
|
retFrameCond := astutil.And(sameGCond, frameoffCondition(retframe))
|
2020-08-08 13:06:14 +00:00
|
|
|
bp, err := allowDuplicateBreakpoint(dbp.SetBreakpoint(retframe.Current.PC, NextBreakpoint, retFrameCond))
|
2017-05-16 18:23:33 +00:00
|
|
|
if err != nil {
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
return err
|
2016-04-14 09:58:59 +00:00
|
|
|
}
|
2018-05-11 12:51:15 +00:00
|
|
|
if bp != nil {
|
2020-03-09 09:47:56 +00:00
|
|
|
configureReturnBreakpoint(dbp.BinInfo(), bp, topframe, retFrameCond)
|
2018-05-11 12:51:15 +00:00
|
|
|
}
|
2016-04-14 09:58:59 +00:00
|
|
|
}
|
|
|
|
|
2017-09-25 06:29:13 +00:00
|
|
|
if bp := curthread.Breakpoint(); bp.Breakpoint == nil {
|
2019-08-12 22:11:19 +00:00
|
|
|
curthread.SetCurrentBreakpoint(false)
|
2017-05-16 18:23:33 +00:00
|
|
|
}
|
|
|
|
|
proc: support inlining
Go 1.10 added inlined calls to debug_info, this commit adds support
for DW_TAG_inlined_call to delve, both for stack traces (where
inlined calls will appear as normal stack frames) and to correct
the behavior of next, step and stepout.
The calls to Next and Frame of stackIterator continue to work
unchanged and only return real stack frames, after reading each line
appendInlinedCalls is called to unpacked all the inlined calls that
involve the current PC.
The fake stack frames produced by appendInlinedCalls are
distinguished from real stack frames by having the Inlined attribute
set to true. Also their Current and Call locations are treated
differently. The Call location will be changed to represent the
position inside the inlined call, while the Current location will
always reference the real stack frame. This is done because:
* next, step and stepout need to access the debug_info entry of
the real function they are stepping through
* we are already manipulating Call in different ways while Current
is just what we read from the call stack
The strategy remains mostly the same, we disassemble the function
and we set a breakpoint on each instruction corresponding to a
different file:line. The function in question will be the one
corresponding to the first real (i.e. non-inlined) stack frame.
* If the current function contains inlined calls, 'next' will not
set any breakpoints on instructions that belong to inlined calls. We
do not do this for 'step'.
* If we are inside an inlined call that makes other inlined
functions, 'next' will not set any breakpoints that belong to
inlined calls that are children of the current inlined call.
* If the current function is inlined the breakpoint on the return
address won't be set, because inlined frames don't have a return
address.
* The code we use for stepout doesn't work at all if we are inside
an inlined call, instead we call 'next' but instruct it to remove
all PCs belonging to the current inlined call.
2017-11-13 15:54:08 +00:00
|
|
|
success = true
|
2020-03-24 16:16:58 +00:00
|
|
|
return dbp.Continue()
|
2016-04-14 09:58:59 +00:00
|
|
|
}
|
|
|
|
|
2020-01-21 20:41:24 +00:00
|
|
|
// StepInstruction will continue the current thread for exactly
|
|
|
|
// one instruction. This method affects only the thread
|
|
|
|
// associated with the selected goroutine. All other
|
|
|
|
// threads will remain stopped.
|
2020-03-24 16:16:58 +00:00
|
|
|
func (dbp *Target) StepInstruction() (err error) {
|
2020-01-21 20:41:24 +00:00
|
|
|
thread := dbp.CurrentThread()
|
|
|
|
g := dbp.SelectedGoroutine()
|
|
|
|
if g != nil {
|
|
|
|
if g.Thread == nil {
|
|
|
|
// Step called on parked goroutine
|
|
|
|
if _, err := dbp.SetBreakpoint(g.PC, NextBreakpoint,
|
2020-03-23 17:57:01 +00:00
|
|
|
sameGoroutineCondition(dbp.SelectedGoroutine())); err != nil {
|
2020-01-21 20:41:24 +00:00
|
|
|
return err
|
|
|
|
}
|
2020-03-24 16:16:58 +00:00
|
|
|
return dbp.Continue()
|
2020-01-21 20:41:24 +00:00
|
|
|
}
|
|
|
|
thread = g.Thread
|
|
|
|
}
|
2021-07-02 16:37:55 +00:00
|
|
|
dbp.ClearCaches()
|
2020-01-21 20:41:24 +00:00
|
|
|
if ok, err := dbp.Valid(); !ok {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
err = thread.StepInstruction()
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2021-05-06 17:33:56 +00:00
|
|
|
thread.Breakpoint().Clear()
|
2020-01-21 20:41:24 +00:00
|
|
|
err = thread.SetCurrentBreakpoint(true)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if tg, _ := GetG(thread); tg != nil {
|
2020-03-10 19:27:38 +00:00
|
|
|
dbp.selectedGoroutine = tg
|
2020-01-21 20:41:24 +00:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
// Set breakpoints at every line, and the return address. Also look for
|
|
|
|
// a deferred function and set a breakpoint there too.
|
|
|
|
// If stepInto is true it will also set breakpoints inside all
|
|
|
|
// functions called on the current source line, for non-absolute CALLs
|
|
|
|
// a breakpoint of kind StepBreakpoint is set on the CALL instruction,
|
|
|
|
// Continue will take care of setting a breakpoint to the destination
|
|
|
|
// once the CALL is reached.
|
|
|
|
//
|
|
|
|
// Regardless of stepInto the following breakpoints will be set:
|
|
|
|
// - a breakpoint on the first deferred function with NextDeferBreakpoint
|
|
|
|
// kind, the list of all the addresses to deferreturn calls in this function
|
|
|
|
// and condition checking that we remain on the same goroutine
|
|
|
|
// - a breakpoint on each line of the function, with a condition checking
|
|
|
|
// that we stay on the same stack frame and goroutine.
|
|
|
|
// - a breakpoint on the return address of the function, with a condition
|
|
|
|
// checking that we move to the previous stack frame and stay on the same
|
|
|
|
// goroutine.
|
|
|
|
//
|
|
|
|
// The breakpoint on the return address is *not* set if the current frame is
|
|
|
|
// an inlined call. For inlined calls topframe.Current.Fn is the function
|
|
|
|
// where the inlining happened and the second set of breakpoints will also
|
|
|
|
// cover the "return address".
|
|
|
|
//
|
|
|
|
// If inlinedStepOut is true this function implements the StepOut operation
|
|
|
|
// for an inlined function call. Everything works the same as normal except
|
|
|
|
// when removing instructions belonging to inlined calls we also remove all
|
|
|
|
// instructions belonging to the current inlined call.
|
|
|
|
func next(dbp *Target, stepInto, inlinedStepOut bool) error {
|
|
|
|
backward := dbp.GetDirection() == Backward
|
|
|
|
selg := dbp.SelectedGoroutine()
|
|
|
|
curthread := dbp.CurrentThread()
|
|
|
|
topframe, retframe, err := topframe(selg, curthread)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
if topframe.Current.Fn == nil {
|
|
|
|
return &ErrNoSourceForPC{topframe.Current.PC}
|
|
|
|
}
|
|
|
|
|
|
|
|
if backward && retframe.Current.Fn == nil {
|
|
|
|
return &ErrNoSourceForPC{retframe.Current.PC}
|
|
|
|
}
|
|
|
|
|
|
|
|
// sanity check
|
|
|
|
if inlinedStepOut && !topframe.Inlined {
|
|
|
|
panic("next called with inlinedStepOut but topframe was not inlined")
|
|
|
|
}
|
|
|
|
|
|
|
|
success := false
|
|
|
|
defer func() {
|
|
|
|
if !success {
|
2021-07-21 15:24:19 +00:00
|
|
|
dbp.ClearSteppingBreakpoints()
|
2020-03-23 17:57:01 +00:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
|
|
|
|
ext := filepath.Ext(topframe.Current.File)
|
|
|
|
csource := ext != ".go" && ext != ".s"
|
|
|
|
var regs Registers
|
|
|
|
if selg != nil && selg.Thread != nil {
|
2020-05-13 18:56:50 +00:00
|
|
|
regs, err = selg.Thread.Registers()
|
2020-03-23 17:57:01 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
sameGCond := sameGoroutineCondition(selg)
|
|
|
|
|
|
|
|
var firstPCAfterPrologue uint64
|
|
|
|
|
|
|
|
if backward {
|
|
|
|
firstPCAfterPrologue, err = FirstPCAfterPrologue(dbp, topframe.Current.Fn, false)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if firstPCAfterPrologue == topframe.Current.PC {
|
|
|
|
// We don't want to step into the prologue so we just execute a reverse step out instead
|
|
|
|
if err := stepOutReverse(dbp, topframe, retframe, sameGCond); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
success = true
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-11-09 19:28:40 +00:00
|
|
|
topframe.Ret, err = findCallInstrForRet(dbp, dbp.Memory(), topframe.Ret, retframe.Current.Fn)
|
2020-03-23 17:57:01 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-09 19:28:40 +00:00
|
|
|
text, err := disassemble(dbp.Memory(), regs, dbp.Breakpoints(), dbp.BinInfo(), topframe.Current.Fn.Entry, topframe.Current.Fn.End, false)
|
2020-03-23 17:57:01 +00:00
|
|
|
if err != nil && stepInto {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2020-09-08 22:18:49 +00:00
|
|
|
var sameFrameCond ast.Expr
|
|
|
|
if sameGCond != nil {
|
|
|
|
sameFrameCond = astutil.And(sameGCond, frameoffCondition(&topframe))
|
|
|
|
}
|
2020-03-23 17:57:01 +00:00
|
|
|
|
|
|
|
if stepInto && !backward {
|
2020-06-05 17:29:28 +00:00
|
|
|
err := setStepIntoBreakpoints(dbp, topframe.Current.Fn, text, topframe, sameGCond)
|
2020-03-23 17:57:01 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !backward {
|
|
|
|
_, err = setDeferBreakpoint(dbp, text, topframe, sameGCond, stepInto)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add breakpoints on all the lines in the current function
|
|
|
|
pcs, err := topframe.Current.Fn.cu.lineInfo.AllPCsBetween(topframe.Current.Fn.Entry, topframe.Current.Fn.End-1, topframe.Current.File, topframe.Current.Line)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
if backward {
|
|
|
|
// Ensure that pcs contains firstPCAfterPrologue when reverse stepping.
|
|
|
|
found := false
|
|
|
|
for _, pc := range pcs {
|
|
|
|
if pc == firstPCAfterPrologue {
|
|
|
|
found = true
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if !found {
|
|
|
|
pcs = append(pcs, firstPCAfterPrologue)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !stepInto {
|
|
|
|
// Removing any PC range belonging to an inlined call
|
|
|
|
frame := topframe
|
|
|
|
if inlinedStepOut {
|
|
|
|
frame = retframe
|
|
|
|
}
|
2020-03-27 21:30:27 +00:00
|
|
|
pcs, err = removeInlinedCalls(pcs, frame)
|
2020-03-23 17:57:01 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !csource {
|
|
|
|
var covered bool
|
|
|
|
for i := range pcs {
|
|
|
|
if topframe.Current.Fn.Entry <= pcs[i] && pcs[i] < topframe.Current.Fn.End {
|
|
|
|
covered = true
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !covered {
|
|
|
|
fn := dbp.BinInfo().PCToFunc(topframe.Ret)
|
|
|
|
if selg != nil && fn != nil && fn.Name == "runtime.goexit" {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, pc := range pcs {
|
|
|
|
if _, err := allowDuplicateBreakpoint(dbp.SetBreakpoint(pc, NextBreakpoint, sameFrameCond)); err != nil {
|
2021-07-21 15:24:19 +00:00
|
|
|
dbp.ClearSteppingBreakpoints()
|
2020-03-23 17:57:01 +00:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if stepInto && backward {
|
|
|
|
err := setStepIntoBreakpointsReverse(dbp, text, topframe, sameGCond)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !topframe.Inlined {
|
2020-03-09 09:47:56 +00:00
|
|
|
topframe, retframe := skipAutogeneratedWrappersOut(selg, curthread, &topframe, &retframe)
|
2020-03-25 11:37:15 +00:00
|
|
|
retFrameCond := astutil.And(sameGCond, frameoffCondition(retframe))
|
2020-03-09 09:47:56 +00:00
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
// Add a breakpoint on the return address for the current frame.
|
|
|
|
// For inlined functions there is no need to do this, the set of PCs
|
|
|
|
// returned by the AllPCsBetween call above already cover all instructions
|
|
|
|
// of the containing function.
|
2021-07-21 15:24:19 +00:00
|
|
|
bp, _ := dbp.SetBreakpoint(retframe.Current.PC, NextBreakpoint, retFrameCond)
|
2020-03-23 17:57:01 +00:00
|
|
|
// Return address could be wrong, if we are unable to set a breakpoint
|
|
|
|
// there it's ok.
|
|
|
|
if bp != nil {
|
2020-03-09 09:47:56 +00:00
|
|
|
configureReturnBreakpoint(dbp.BinInfo(), bp, topframe, retFrameCond)
|
2020-03-23 17:57:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if bp := curthread.Breakpoint(); bp.Breakpoint == nil {
|
|
|
|
curthread.SetCurrentBreakpoint(false)
|
|
|
|
}
|
|
|
|
success = true
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-06-05 17:29:28 +00:00
|
|
|
func setStepIntoBreakpoints(dbp *Target, curfn *Function, text []AsmInstruction, topframe Stackframe, sameGCond ast.Expr) error {
|
2020-03-23 17:57:01 +00:00
|
|
|
for _, instr := range text {
|
|
|
|
if instr.Loc.File != topframe.Current.File || instr.Loc.Line != topframe.Current.Line || !instr.IsCall() {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
if instr.DestLoc != nil {
|
2020-06-05 17:29:28 +00:00
|
|
|
if err := setStepIntoBreakpoint(dbp, curfn, []AsmInstruction{instr}, sameGCond); err != nil {
|
2020-03-23 17:57:01 +00:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// Non-absolute call instruction, set a StepBreakpoint here
|
|
|
|
if _, err := allowDuplicateBreakpoint(dbp.SetBreakpoint(instr.Loc.PC, StepBreakpoint, sameGCond)); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-06-03 18:14:14 +00:00
|
|
|
func setStepIntoBreakpointsReverse(dbp *Target, text []AsmInstruction, topframe Stackframe, sameGCond ast.Expr) error {
|
2021-07-21 15:24:19 +00:00
|
|
|
bpmap := dbp.Breakpoints()
|
2020-03-23 17:57:01 +00:00
|
|
|
// Set a breakpoint after every CALL instruction
|
|
|
|
for i, instr := range text {
|
|
|
|
if instr.Loc.File != topframe.Current.File || !instr.IsCall() || instr.DestLoc == nil || instr.DestLoc.Fn == nil {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2020-03-09 09:47:56 +00:00
|
|
|
if instr.DestLoc.Fn.privateRuntime() {
|
2020-03-23 17:57:01 +00:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
if nextIdx := i + 1; nextIdx < len(text) {
|
2021-07-21 15:24:19 +00:00
|
|
|
_, ok := bpmap.M[text[nextIdx].Loc.PC]
|
|
|
|
if !ok {
|
|
|
|
if _, err := allowDuplicateBreakpoint(dbp.SetBreakpoint(text[nextIdx].Loc.PC, StepBreakpoint, sameGCond)); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-03-23 17:57:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func FindDeferReturnCalls(text []AsmInstruction) []uint64 {
|
|
|
|
const deferreturn = "runtime.deferreturn"
|
|
|
|
deferreturns := []uint64{}
|
|
|
|
|
|
|
|
// Find all runtime.deferreturn locations in the function
|
|
|
|
// See documentation of Breakpoint.DeferCond for why this is necessary
|
|
|
|
for _, instr := range text {
|
|
|
|
if instr.IsCall() && instr.DestLoc != nil && instr.DestLoc.Fn != nil && instr.DestLoc.Fn.Name == deferreturn {
|
|
|
|
deferreturns = append(deferreturns, instr.Loc.PC)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return deferreturns
|
|
|
|
}
|
|
|
|
|
|
|
|
// Removes instructions belonging to inlined calls of topframe from pcs.
|
|
|
|
// If includeCurrentFn is true it will also remove all instructions
|
|
|
|
// belonging to the current function.
|
2020-03-27 21:30:27 +00:00
|
|
|
func removeInlinedCalls(pcs []uint64, topframe Stackframe) ([]uint64, error) {
|
2020-03-23 17:57:01 +00:00
|
|
|
dwarfTree, err := topframe.Call.Fn.cu.image.getDwarfTree(topframe.Call.Fn.offset)
|
|
|
|
if err != nil {
|
|
|
|
return pcs, err
|
|
|
|
}
|
|
|
|
for _, e := range reader.InlineStack(dwarfTree, 0) {
|
|
|
|
if e.Offset == topframe.Call.Fn.offset {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
for _, rng := range e.Ranges {
|
|
|
|
pcs = removePCsBetween(pcs, rng[0], rng[1])
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return pcs, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func removePCsBetween(pcs []uint64, start, end uint64) []uint64 {
|
|
|
|
out := pcs[:0]
|
|
|
|
for _, pc := range pcs {
|
|
|
|
if pc < start || pc >= end {
|
|
|
|
out = append(out, pc)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return out
|
|
|
|
}
|
|
|
|
|
2020-06-05 17:29:28 +00:00
|
|
|
func setStepIntoBreakpoint(dbp *Target, curfn *Function, text []AsmInstruction, cond ast.Expr) error {
|
2020-03-23 17:57:01 +00:00
|
|
|
if len(text) <= 0 {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-06-05 17:29:28 +00:00
|
|
|
// If the current function is already a runtime function then
|
|
|
|
// setStepIntoBreakpoint is allowed to step into unexported runtime
|
|
|
|
// functions.
|
|
|
|
stepIntoUnexportedRuntime := curfn != nil && strings.HasPrefix(curfn.Name, "runtime.")
|
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
instr := text[0]
|
|
|
|
|
|
|
|
if instr.DestLoc == nil {
|
|
|
|
// Call destination couldn't be resolved because this was not the
|
|
|
|
// current instruction, therefore the step-into breakpoint can not be set.
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
fn := instr.DestLoc.Fn
|
|
|
|
|
|
|
|
// Skip unexported runtime functions
|
2020-06-05 17:29:28 +00:00
|
|
|
if !stepIntoUnexportedRuntime && fn != nil && fn.privateRuntime() {
|
2020-03-23 17:57:01 +00:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
//TODO(aarzilli): if we want to let users hide functions
|
|
|
|
// or entire packages from being stepped into with 'step'
|
|
|
|
// those extra checks should be done here.
|
|
|
|
|
|
|
|
pc := instr.DestLoc.PC
|
|
|
|
|
|
|
|
// Skip InhibitStepInto functions for different arch.
|
2020-03-30 18:03:29 +00:00
|
|
|
if dbp.BinInfo().Arch.inhibitStepInto(dbp.BinInfo(), pc) {
|
2020-03-23 17:57:01 +00:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-03-09 09:47:56 +00:00
|
|
|
fn, pc = skipAutogeneratedWrappersIn(dbp, fn, pc)
|
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
// We want to skip the function prologue but we should only do it if the
|
|
|
|
// destination address of the CALL instruction is the entry point of the
|
|
|
|
// function.
|
|
|
|
// Calls to runtime.duffzero and duffcopy inserted by the compiler can
|
|
|
|
// sometimes point inside the body of those functions, well after the
|
|
|
|
// prologue.
|
2020-03-09 09:47:56 +00:00
|
|
|
if fn != nil && fn.Entry == pc {
|
2020-03-23 17:57:01 +00:00
|
|
|
pc, _ = FirstPCAfterPrologue(dbp, fn, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
// Set a breakpoint after the function's prologue
|
|
|
|
if _, err := allowDuplicateBreakpoint(dbp.SetBreakpoint(pc, NextBreakpoint, cond)); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
func allowDuplicateBreakpoint(bp *Breakpoint, err error) (*Breakpoint, error) {
|
|
|
|
if err != nil {
|
|
|
|
if _, isexists := err.(BreakpointExistsError); isexists {
|
|
|
|
return bp, nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return bp, err
|
|
|
|
}
|
|
|
|
|
2020-03-09 09:47:56 +00:00
|
|
|
func isAutogenerated(loc Location) bool {
|
|
|
|
return loc.File == "<autogenerated>" && loc.Line == 1
|
|
|
|
}
|
|
|
|
|
|
|
|
// skipAutogeneratedWrappers skips autogenerated wrappers when setting a
|
|
|
|
// step-into breakpoint.
|
|
|
|
// See genwrapper in: $GOROOT/src/cmd/compile/internal/gc/subr.go
|
|
|
|
func skipAutogeneratedWrappersIn(p Process, startfn *Function, startpc uint64) (*Function, uint64) {
|
|
|
|
if startfn == nil {
|
|
|
|
return nil, startpc
|
|
|
|
}
|
|
|
|
fn := startfn
|
|
|
|
for count := 0; count < maxSkipAutogeneratedWrappers; count++ {
|
|
|
|
if !fn.cu.isgo {
|
|
|
|
// can't exit Go
|
|
|
|
return startfn, startpc
|
|
|
|
}
|
2020-11-09 19:28:40 +00:00
|
|
|
text, err := Disassemble(p.Memory(), nil, p.Breakpoints(), p.BinInfo(), fn.Entry, fn.End)
|
2020-03-09 09:47:56 +00:00
|
|
|
if err != nil {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
if len(text) == 0 {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
if !isAutogenerated(text[0].Loc) {
|
|
|
|
return fn, fn.Entry
|
|
|
|
}
|
|
|
|
tgtfns := []*Function{}
|
|
|
|
// collect all functions called by the current destination function
|
|
|
|
for _, instr := range text {
|
|
|
|
switch {
|
|
|
|
case instr.IsCall():
|
|
|
|
if instr.DestLoc == nil || instr.DestLoc.Fn == nil {
|
|
|
|
return startfn, startpc
|
|
|
|
}
|
|
|
|
// calls to non private runtime functions
|
|
|
|
if !instr.DestLoc.Fn.privateRuntime() {
|
|
|
|
tgtfns = append(tgtfns, instr.DestLoc.Fn)
|
|
|
|
}
|
|
|
|
case instr.IsJmp():
|
|
|
|
// unconditional jumps to a different function that isn't a private runtime function
|
|
|
|
if instr.DestLoc != nil && instr.DestLoc.Fn != fn && !instr.DestLoc.Fn.privateRuntime() {
|
|
|
|
tgtfns = append(tgtfns, instr.DestLoc.Fn)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if len(tgtfns) != 1 {
|
|
|
|
// too many or not enough function calls
|
|
|
|
break
|
|
|
|
}
|
|
|
|
|
|
|
|
tgtfn := tgtfns[0]
|
|
|
|
if tgtfn.BaseName() != fn.BaseName() {
|
|
|
|
return startfn, startpc
|
|
|
|
}
|
|
|
|
fn = tgtfn
|
|
|
|
}
|
|
|
|
return startfn, startpc
|
|
|
|
}
|
|
|
|
|
|
|
|
// skipAutogeneratedWrappersOut skip autogenerated wrappers when setting a
|
|
|
|
// step out breakpoint.
|
|
|
|
// See genwrapper in: $GOROOT/src/cmd/compile/internal/gc/subr.go
|
|
|
|
func skipAutogeneratedWrappersOut(g *G, thread Thread, startTopframe, startRetframe *Stackframe) (topframe, retframe *Stackframe) {
|
|
|
|
topframe, retframe = startTopframe, startRetframe
|
|
|
|
if startTopframe.Ret == 0 {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
if !isAutogenerated(startRetframe.Current) {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
retfn := thread.BinInfo().PCToFunc(startTopframe.Ret)
|
|
|
|
if retfn == nil {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
if !retfn.cu.isgo {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
var err error
|
|
|
|
var frames []Stackframe
|
|
|
|
if g == nil {
|
|
|
|
frames, err = ThreadStacktrace(thread, maxSkipAutogeneratedWrappers)
|
|
|
|
} else {
|
|
|
|
frames, err = g.Stacktrace(maxSkipAutogeneratedWrappers, 0)
|
|
|
|
}
|
|
|
|
if err != nil {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
for i := 1; i < len(frames); i++ {
|
|
|
|
frame := frames[i]
|
|
|
|
if frame.Current.Fn == nil {
|
|
|
|
return
|
|
|
|
}
|
2020-07-21 20:44:04 +00:00
|
|
|
file, line := frame.Current.Fn.cu.lineInfo.PCToLine(frame.Current.Fn.Entry, frame.Current.Fn.Entry)
|
|
|
|
if !isAutogenerated(Location{File: file, Line: line, Fn: frame.Current.Fn}) {
|
2020-03-09 09:47:56 +00:00
|
|
|
return &frames[i-1], &frames[i]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
// setDeferBreakpoint is a helper function used by next and StepOut to set a
|
|
|
|
// breakpoint on the first deferred function.
|
2020-06-03 18:14:14 +00:00
|
|
|
func setDeferBreakpoint(p *Target, text []AsmInstruction, topframe Stackframe, sameGCond ast.Expr, stepInto bool) (uint64, error) {
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
// Set breakpoint on the most recently deferred function (if any)
|
|
|
|
var deferpc uint64
|
2021-07-08 15:47:53 +00:00
|
|
|
if topframe.TopmostDefer != nil && topframe.TopmostDefer.DwrapPC != 0 {
|
|
|
|
_, _, deferfn := topframe.TopmostDefer.DeferredFunc(p)
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
var err error
|
|
|
|
deferpc, err = FirstPCAfterPrologue(p, deferfn, false)
|
|
|
|
if err != nil {
|
|
|
|
return 0, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if deferpc != 0 && deferpc != topframe.Current.PC {
|
|
|
|
bp, err := allowDuplicateBreakpoint(p.SetBreakpoint(deferpc, NextDeferBreakpoint, sameGCond))
|
|
|
|
if err != nil {
|
|
|
|
return 0, err
|
|
|
|
}
|
|
|
|
if bp != nil && stepInto {
|
|
|
|
// If DeferReturns is set then the breakpoint will also be triggered when
|
|
|
|
// called from runtime.deferreturn. We only do this for the step command,
|
|
|
|
// not for next or stepout.
|
2021-07-21 15:24:19 +00:00
|
|
|
for _, breaklet := range bp.Breaklets {
|
|
|
|
if breaklet.Kind == NextDeferBreakpoint {
|
|
|
|
breaklet.DeferReturns = FindDeferReturnCalls(text)
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return deferpc, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// findCallInstrForRet returns the PC address of the CALL instruction
|
|
|
|
// immediately preceding the instruction at ret.
|
|
|
|
func findCallInstrForRet(p Process, mem MemoryReadWriter, ret uint64, fn *Function) (uint64, error) {
|
|
|
|
text, err := disassemble(mem, nil, p.Breakpoints(), p.BinInfo(), fn.Entry, fn.End, false)
|
|
|
|
if err != nil {
|
|
|
|
return 0, err
|
|
|
|
}
|
|
|
|
var prevInstr AsmInstruction
|
|
|
|
for _, instr := range text {
|
|
|
|
if instr.Loc.PC == ret {
|
|
|
|
return prevInstr.Loc.PC, nil
|
|
|
|
}
|
|
|
|
prevInstr = instr
|
|
|
|
}
|
|
|
|
return 0, fmt.Errorf("could not find CALL instruction for address %#x in %s", ret, fn.Name)
|
|
|
|
}
|
|
|
|
|
|
|
|
// stepOutReverse sets a breakpoint on the CALL instruction that created the current frame, this is either:
|
|
|
|
// - the CALL instruction immediately preceding the return address of the
|
|
|
|
// current frame
|
|
|
|
// - the return address of the current frame if the current frame was
|
|
|
|
// created by a runtime.deferreturn run
|
|
|
|
// - the return address of the runtime.gopanic frame if the current frame
|
|
|
|
// was created by a panic
|
|
|
|
// This function is used to implement reversed StepOut
|
|
|
|
func stepOutReverse(p *Target, topframe, retframe Stackframe, sameGCond ast.Expr) error {
|
|
|
|
curthread := p.CurrentThread()
|
|
|
|
selg := p.SelectedGoroutine()
|
|
|
|
|
|
|
|
if selg != nil && selg.Thread != nil {
|
|
|
|
curthread = selg.Thread
|
|
|
|
}
|
|
|
|
|
2020-11-09 19:28:40 +00:00
|
|
|
callerText, err := disassemble(p.Memory(), nil, p.Breakpoints(), p.BinInfo(), retframe.Current.Fn.Entry, retframe.Current.Fn.End, false)
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
deferReturns := FindDeferReturnCalls(callerText)
|
|
|
|
|
|
|
|
var frames []Stackframe
|
|
|
|
if selg == nil {
|
2020-11-09 19:28:40 +00:00
|
|
|
frames, err = ThreadStacktrace(curthread, 3)
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
} else {
|
|
|
|
frames, err = selg.Stacktrace(3, 0)
|
|
|
|
}
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
var callpc uint64
|
|
|
|
|
2021-07-08 15:47:53 +00:00
|
|
|
if ok, panicFrame := isPanicCall(frames); ok {
|
|
|
|
if len(frames) < panicFrame+2 || frames[panicFrame+1].Current.Fn == nil {
|
|
|
|
if panicFrame < len(frames) {
|
|
|
|
return &ErrNoSourceForPC{frames[panicFrame].Current.PC}
|
|
|
|
} else {
|
|
|
|
return &ErrNoSourceForPC{frames[0].Current.PC}
|
|
|
|
}
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
}
|
2021-07-08 15:47:53 +00:00
|
|
|
callpc, err = findCallInstrForRet(p, p.Memory(), frames[panicFrame].Ret, frames[panicFrame+1].Current.Fn)
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
} else if ok, pc := isDeferReturnCall(frames, deferReturns); ok {
|
|
|
|
callpc = pc
|
|
|
|
} else {
|
2020-11-09 19:28:40 +00:00
|
|
|
callpc, err = findCallInstrForRet(p, p.Memory(), topframe.Ret, retframe.Current.Fn)
|
proc,terminal: Implement reverse step, next and stepout (#1785)
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
2020-03-11 22:40:41 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
_, err = allowDuplicateBreakpoint(p.SetBreakpoint(callpc, NextBreakpoint, sameGCond))
|
|
|
|
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
// onNextGoroutine returns true if this thread is on the goroutine requested by the current 'next' command
|
2021-08-09 17:16:24 +00:00
|
|
|
func onNextGoroutine(tgt *Target, thread Thread, breakpoints *BreakpointMap) (bool, error) {
|
2021-07-21 15:24:19 +00:00
|
|
|
var breaklet *Breaklet
|
|
|
|
breakletSearch:
|
2020-03-23 17:57:01 +00:00
|
|
|
for i := range breakpoints.M {
|
2021-07-21 15:24:19 +00:00
|
|
|
for _, blet := range breakpoints.M[i].Breaklets {
|
|
|
|
if blet.Kind&steppingMask != 0 && blet.Cond != nil {
|
|
|
|
breaklet = blet
|
|
|
|
break breakletSearch
|
|
|
|
}
|
2018-12-06 08:32:20 +00:00
|
|
|
}
|
2015-08-28 20:06:29 +00:00
|
|
|
}
|
2021-07-21 15:24:19 +00:00
|
|
|
if breaklet == nil {
|
2020-03-23 17:57:01 +00:00
|
|
|
return false, nil
|
2020-01-14 15:22:33 +00:00
|
|
|
}
|
2020-03-23 17:57:01 +00:00
|
|
|
// Internal breakpoint conditions can take multiple different forms:
|
|
|
|
// Step into breakpoints:
|
|
|
|
// runtime.curg.goid == X
|
|
|
|
// Next or StepOut breakpoints:
|
|
|
|
// runtime.curg.goid == X && runtime.frameoff == Y
|
|
|
|
// Breakpoints that can be hit either by stepping on a line in the same
|
|
|
|
// function or by returning from the function:
|
|
|
|
// runtime.curg.goid == X && (runtime.frameoff == Y || runtime.frameoff == Z)
|
|
|
|
// Here we are only interested in testing the runtime.curg.goid clause.
|
2021-08-09 17:16:24 +00:00
|
|
|
w := onNextGoroutineWalker{tgt: tgt, thread: thread}
|
2021-07-21 15:24:19 +00:00
|
|
|
ast.Walk(&w, breaklet.Cond)
|
2020-03-23 17:57:01 +00:00
|
|
|
return w.ret, w.err
|
2015-08-28 20:06:29 +00:00
|
|
|
}
|
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
type onNextGoroutineWalker struct {
|
2021-08-09 17:16:24 +00:00
|
|
|
tgt *Target
|
2020-03-23 17:57:01 +00:00
|
|
|
thread Thread
|
|
|
|
ret bool
|
|
|
|
err error
|
2015-08-28 20:06:29 +00:00
|
|
|
}
|
2015-10-09 23:30:28 +00:00
|
|
|
|
2020-03-23 17:57:01 +00:00
|
|
|
func (w *onNextGoroutineWalker) Visit(n ast.Node) ast.Visitor {
|
|
|
|
if binx, isbin := n.(*ast.BinaryExpr); isbin && binx.Op == token.EQL && exprToString(binx.X) == "runtime.curg.goid" {
|
2021-08-09 17:16:24 +00:00
|
|
|
w.ret, w.err = evalBreakpointCondition(w.tgt, w.thread, n.(ast.Expr))
|
2020-03-23 17:57:01 +00:00
|
|
|
return nil
|
2020-03-02 15:38:56 +00:00
|
|
|
}
|
2020-03-23 17:57:01 +00:00
|
|
|
return w
|
2020-03-02 15:38:56 +00:00
|
|
|
}
|