* service/dap: Implement suspended breakpoints
This enables support for 'suspended' breakpoints, for example for a
plugin that hasn't been loaded yet.
Fixes#4074
* Address comments
* Cleanup
* Skip TestIssue256 on linux/386, it fails because the line it relies
on
(a return) does not have code generated for it.
* Skip running gen-usage-docs in TestGeneratedDocs on linux/ppc64le, I
don't know why this fails, likely just a problem with the build
agent,
but it doesn't matter: the test doesn't need to run on every
architecture.
* Change TestRestartRequestWithNewArgs so that it doesn't depend on the
cap value of a slice (it changed in go1.25/windows/amd64)
Replaces the Thread.Location method with a ThreadLocation function. All
backends implemented the Location method exactly the same way, this
change deduplicates it.
Expose breakpoint hitcounts in the expression language through the
special variable runtime.bphitcount:
delve.bphitcount[1]
delve.bphitcount["bpname"]
will evaluate respectively to the hitcount of breakpoint with id == 1
and to the hitcount of the breakpoint named "bpname".
This is intended to be used in breakpoint conditions and allows
breakpoints to be chained such that one breakpoint is only hit after a
different is hit first.
A few optimizations are implemented so that chained breakpoints are
evaluated efficiently.
Adds support for setting a watchpoint on an interface by setting
the watchpoint on the data pointer in the eface/iface runtime
structs representing the interface.
* delve: support linux-loong64 native debug
LoongArch is a new RISC ISA, which is independently designed by Loongson Technology.
LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit version (LA32S)
and a 64-bit version (LA64), and loong64 is the 64-bit version of LoongArch.
LoongArch documentation: https://github.com/loongson/LoongArch-Documentation.git
* *: mark loong64 port as experimental
---------
Co-authored-by: Huang Qiqi <huangqiqi@loongson.cn>
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.
Once upon a time Go version strings for development builds did not
reference the major/minor version they belonged to, therefore the best
we could do was to always assume that a development build belonged to
the most recently released version of Go.
This commit changes pkg/goversion so that the new style of development
version string is fully parsed.
Move all tests of the functionality of proc.next,
proc.(*TargetGroup).Next, proc.(*TargetGroup).Step,
proc.(*TargetGroup).StepOut to their own test file.
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
Supports viewing local variables and evaluating expressions correctly
when range-over-func is used.
The same limitations that the previous commit on this line had still
apply (no inlining, wrong way to identify the range parent in some
cases).
Updates #3733
Because of how range-over-func is implemented it is difficult to
determine the set of visible local variables during expression
compilation (i.e. it is difficulto to keep the HasLocal function
correct).
This commit moves that logic from expression compilation to expression
evaluation.
Updates #3733
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
It seems newer MacOS kernels are sending mach exceptions for watchpoints
which contain the hardware register number as opposed to the address
which triggered the exception. Also, ARM64 seems to have switched to
sending _EXC_I386_SGL as medata[0] for this exception type.
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.
The `scope.Locals` function did not have any guard checks against missing DWARF information.
This patch adds a check, which likely will need to be added to other functions as well.
The builder is currently spending 15 to 20 minutes installing gcc and
upgrading packages every time we run the tests.
Because of this the build fails sometimes by running out of time.
This change reduces that to 5 minutes by:
* switching from curl to wget (which seems to have fewer dependencies)
* not installing gcc on ppc64le
* skipping tests that depend on gcc or other binutils
Go1.22 has changed some line number assignments. The new line number
assignments are still valid however some tests in dap relied on them
being different and broke as a result. This commit fixes those tests
and makes them less brittle.
Also disables TestDebugStripped and TestDebugStripped2 temporarily on
1.22.
If the target process exits and receives a signal at the same time and
we receive the signal first we should call waitpid again to read the
target's exit status.
This also fixes a nil pointer dereference when trapWaitInternal returns
an error, this fix is probably incomplete but I wasn't able to
reproduce its circumstances after 30000 runs of TestIssue1101 to
properly address it.
This patch switches from using a forked version of one of the libraries
of goretk/gore to using the module directly. This is possible now that
certain functionality has been exposed / fixed within that module making
it usable for Delve.
We had a few checks left over for the TRAVIS variable that detected if
we were running under the TravisCI build system.
This variable hasn't been set since 2020.
