The rangeParent calculation was changed 0b74953f0 to address slowness
(due to repeated calculations) when calling PackageVariables. That
changed caused to program to use a lot of memory due to having to
calculate the range bodies of every function. This change reverts
0b74953f0 and splits off rangeBodies calculation from the extras method
of Function, so that it isn't called from PackageVariables.
Fixes#4146
Adds an RPC call to cancel in-progress debuginfod-find downloads. Wires
this call to ^C in the terminal interface and to receiving a Pause
request while already pausing in DAP.
Adds a new terminal command to download the debug info for libraries
for which it hasn't been downloaded already.
Fixes#3906
Replaces the Thread.Location method with a ThreadLocation function. All
backends implemented the Location method exactly the same way, this
change deduplicates it.
* deduplicates exprToString, defined in multiple packages, and moves it
to astutil
* moves resolveTypedef into pkg/dwarf/godwarf, this is currently only
used by pkg/proc but we will need to call it from pkg/proc/evalop
* creates a new FakePointerType function in pkg/dwarf/godwarf, this is
also a function that is only used by pkg/proc but pkg/proc/evalop will
also need.
Updates #1465
Previously breakpoints with hitcount conditions that became
unsatisfiable
would become disabled, this was done as an optimization so that the
continue loop would no longer need to stop on them and evaluate their
conditions.
As a side effect this meant that on restart these breakpoints would
remain disabled, even though their hit condition returned satisfiable.
This commit changes Delve behavior so that breakpoints with
unsatisifiable hitcount conditions are no longer disabled but the
associated physical breakpoints are removed anyway, preserving the
optimization.
Some refactoring is done to the way conditions are represented and the
enable status is managed so that in the future it will be possible to
use hitcount conditions to implement "chained" breakpoints (also known
as dependet breakpoints), i.e. breakpoints that become active only
after a second breakpoint has been hit.
This commit adds a new mode to call injection. If the runtime.debugPinner
function is available in the target executable it obtains a pinner by
calling it and then uses it to pin the pointers in the results of call
injection.
This allows the code for call injection to be refactored to execute the
calls in the normal order, since it doesn't need to be concerned with having
space on the target's memory to store intermediate values.
Updates #3310
The step command is changed such that when the function being currently
called is a coroutine switch function it will move to the associated
coroutine.
Functions that switch coroutines are currently the next, stop and yield
closures produced by the iter.Pull function.
Fixes a repeated stop on the first line of a range-over-func body when
stepping through a program. The entry point breakpoint is changed to a
special breakpoint that, when hit:
- clears the current temporary breakpoints
- sets breakpoints like 'next' would, and
- resumes execution.
Set a breakpoint on the return address of the current function, if it's
a range-over-func body, and clear the stepping breakpoints for the
current function (except the entry one) when its hit.
Without this what can happen is the following:
1. the range-over-func body finishes and returns to the iterator
2. the iterator calls back into the range-over-func body
3. a stepping breakpoint that's inside the prologue gets hit
Updates #3733
* proc: use .closureptr for stepping through range-over-func statements
Uses special variables .closureptr and #yieldN to correctly identify
the parent frame of a range-over-func body closure call.
Updates #3733
* fix
When stack watchpoints go out of scope simultaneously they can hide (or
duplicate the effect) of other breakpoints (including other watchpoints
going out of scope) that are placed on the same physical memory
location.
This happens because we delete the watchpoint-out-of-scope breakpoint
while we are evaluating hit breakpoints, mangling the breaklets list.
This commit moves breakpoint deletion out of the
watchpoint-out-of-scope condition, delaying it until all hit
breakpoints have been evaluated.
Also fix bug where on amd64 if all four watchpoints are in use the last
one is not checked.
Fixes#3739
Initial support for stepping in functions that use the new
range-over-func statement in go1.23.
Does not support:
- inlining
- viewing variables of the enclosing function from a range-over-func
body closure
- the correct way to find the enclosing function from a range-over-func
body closure (but it should work most of the time).
Updates #3733
Change 'step' command so that when stepping into a 'go statement' the
debugger will stop on the newly created goroutine, instead of just
stepping over the go statement.
We used to autoremove the trace recorded by rr but as a result of
various refactorings done to implement follow exec mode this broke.
Restore the functionality.
Also remove the _fixtures/testfnpos.go file which is autogenerated
during testing.
The flake manifests as an error where the variable i can not be found in
frame 1 and happens in go1.22rc1 between 0.1% and 0.5% of the time (it is highly dependent on CPU contention)
This problem is caused by the new code in evalop.PushLocal referencing the
stale value of SelectedGoroutine. This happens because:
- evalop.PushLocal calls ConvertEvalScope
- ConvertEvalScope calls FindGoroutine
- FindGoroutine checks the value of selectedGoroutine
When breakpoint conditions are evaluated both the value of selectedGoroutine
and currentThread are stale because we can only set their definitive value
*after* all breakpoint conditions have been evaluated.
The fact that it only happens in 1.22rc1 is coincidental, it's probably
caused by the fact that 1.22rc1 migrates goroutines between threads more in
this particular circumstance.
This commit fixes the problem in two ways:
1. selectedGoroutine and currentThread are given temprorary non-stale values
before breakpoint conditions are evaluated
2. evalop.PushLocal is changed so it takes a stack trace of the current
thread rather than resolving it through the selected goroutine.
Either one would suffice however I think we should do both, (2) ensures that
the runtime.frame(n).var will work even if the current thread is not running
any goroutine and (1) ensures that we don't accidentally reference a stale
selectedGoroutine in the future.
When using debugserver as a backend a manual stop request can end up
looking like an hardcoded breakpoint if the thread that receives the
stop request happens to be stopped right after a hardcoded breakpoint
(and the space between functions is filled with hardcoded breakpoints).
When creating hardcoded breakpoints we should ignore the trapthread if
a manual stop has been requested.
This problem made TestSetBreakpointWhileRunning and
TestSetFunctionBreakpointWhileRunning fail on macOS between 1.7% and 6%
of the time.
TestIssue1376 in rr_test.go used to pass accidentally, the stop when
the start of the recording was reached was mistaken for a hardcoded
breakpoint.
Use the trampoline attribute to detect auto-generated code. This fixes
a bug where stepping into a method of a generic type called through an
interface will take the debugger into an auto-generated wrapper that
does not have a dictionary and using next will step out of the wrapper.
Fixes a bug reported on the #delve channel of the gophers slack server.
* proc: correctly update local variables after continue
At various point during the execution of the call injection protocol
the process is resumed and the call injection goroutine could migrate
to a different thread, we must make sure to update our local variables
correctly after every point where the target program is resumed.
'fncall122debug_clean' on 'f469a0a5'.
* go.mod: update golang.org/x/tools
Go 1.22 broke golang.org/x/tools/packages
* cmd/dlv: disable TestStaticcheck with go1.22
Go 1.22 is not yet supported by staticcheck.
If there is no current goroutine when 'next', 'step' or 'stepout' are
used set a condition that the thread ID should stay the same instead.
This makes stepping work for multithreaded C programs or Go programs
that have threads started by cgo code.
Fixes#3262
* logflags,proc: flag to log stacktrace execution
Add a log flag to write logs about what the stacktracer does.
* proc: read context from sigtrampgo, fixes TestCgoStacktrace2 on 1.21
Changes stacktrace code to read the signal context from the arguments
of sigtrampgo.
Also changes the automatic fatalthrow breakpoint for go 1.21.
In combination these two changes fix TestCgoStacktrace2 on Go 1.21 on
various platforms.
We used to parse the .gopclntab section but removed support in favor of
simply using DWARF debug information, due to lack of C symbols among
other reasons. This makes it impossible to debug stripped binaries,
which some distrubutions ship by default.
Add back in basic support for .gopclntab which survives if the binary
is stripped, allowing for rudimentary debugging such as basic
program navigation, tracing, etc...
When using Step on a function that has a dynamic CALL instruction we
set a Step breakpoint on the call.
When it is hit we determine the destination of the CALL by looking at
registers, set a breakpoint there and continue.
If the Step breakpoint is hit simultaneously with a normal breakpoint
our Step logic will take precedence and the normal breakpoint hit will
be hidden from the user.
Move the Step logic to a breaklet callback so that it does not
interfere with the decision to stop.
Adds the ability to automatically debug child processes executed by the
target to the linux native backend.
This commit does not contain user interface or API to access this
functionality.
Updates #2551
Introduces a new TargetGroup abstraction that can be used to manage
multiple related targets.
No actual management of child processes is implemented here, this is
just a refactoring to make it possible to do that in the future.
Updates #2551
Go 1.19 also formats doc comments according to the new godoc syntax.
Some of our comments, especially unexported symbols did not conform to
the godoc syntax and therefore are mangled by 'go fmt'.
This PR runs 'go fmt' from go1.19 on everything and manually fixes the
problems.
See also:
https://github.com/golang/proposal/blob/master/design/51082-godocfmt.md
Adds a LogicalBreakpoint type to represent logical breakpoints
explicitly. Until now logical breakpoints were constructed implicitly
by grouping physical breakpoints together by their LogicalID.
Having logical breakpoints represented explicitly allows for a simpler
implementation of disabled breakpoints, as well as allowing a simple
implementation of delayed breakpoints (#1653, #2551) and in general of
breakpoints spanning multiple processes if we implement debugging
process trees (#2551).
Updates #1653
Updates #2551
The fix in #2959 was incomplete and the skip was still broken on
linux/386 for PIE builds due to calls to the get_pc_thunk helper.
Co-authored-by: a <a@kra>
Moves breakpoindIDCounter out of BreakpointsMap and into
service/debugger.Debuggger to simplify proc.Target's API and aid with
implementing fork follow mode, where we'll have to debug multiple
processes simultaneously.
This commit improves the handling of hardcoded breakpoints in Delve.
A hardcoded breakpoint is a breakpoint instruction hardcoded in the
text of the program, for example through runtime.Breakpoint.
1. hardcoded breakpoints are now indicated by setting the breakpoint
field on any thread stopped by a hardcoded breakpoint
2. if multiple hardcoded breakpoints are hit during a single stop all
will be notified to the user.
3. a debugger breakpoint with an unmet condition can't hide a hardcoded
breakpoint anymore.
Normally calls can't be performed on recorded processes, becuase the
future instructions executed by the target are predetermined. The rr
debugger however has a mechanism that allows this by taking the current
state of the recording and allowing it to diverge from the recording,
temporarily.
This commit adds support for starting and ending such diversions around
function calls.
Note: this requires rr version 5.5 of later to work, see:
https://github.com/rr-debugger/rr/pull/2748
