Structs returned to starlark scripts by API calls were immutable, this
made amend_breakpoint nearly impossible to use since its argument must
be a api.Breakpoint struct which the caller has received from
get_breakpoint and modified.
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.
When the Delve instance is running in a detached state and it launches
a process an additional child conhost.exe process will be created, we
should detach from it.
Fixes#3864
- move the cpuid querying code to pkg/proc/native/cpuid since
pkg/proc/native is the only package entitled to calling it
- add a type to describe the xstate_bv bitmap instead of using
hardcoded constants everywhere
- use xcr0 instead of xstate_bv for the offset heuristic like gdb does
This is probably the cause of the panic such as in issue #3848 and
other similar issues, it is hard to be sure because we never get a
proper reproducer but judging from the stack traces it should be this.
Also it doesn't affect versions of Go that have the debug pinner.
Fixes#3848
If an inlined function is encountered we should keep searching for its
rangeParent even if we don't have a closurePtr because it could be that
the function has been inlined into its rangeParent.
This does not need a new test, the existing tests already fail on
go1.24.
The offset of state component i can be found via
CPUID.(EAX=0DH,ECX=i):EBX. The ZMM_Hi256 is state component 6, so we use
CPUID to enumerate the offset instead of hardcoding.
For core dumps, we guess the ZMM_Hi256 offset based on xcr0 and the
length of xsave region. The logic comes from binutils-gdb.
Fixes#3827.
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.
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
Change the examinemem command to have a new format 'raw' that just
prints the raw memory bytes.
Change the transcript command to add a new flag that disables prompt
echo to the output file.
Fixes#3706
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.
* proc: flag variables correctly when range-over-func stmts are used
Argument variables of a range-over-func body closure should be returned
flagged as normal local variables, not as function arguments.
Updates #3806
* proc: for optimized functions allow .closureptr to not exist
For optimized functions .closureptr is sometimes omitted from DWARF,
allow it to be 0 and try to recover the range-over-func stack by best
effort.
Fixes#3806
We have a check for Rosetta that should point users towards
misconfiguration, however occasionally we still get new issues about
debugserver crashing and some of those, as it turns out, are still
caused by Rosetta (see for example #3804).
Check the output of 'uname -m' and check that it isn't 'x86_64' if we
are an 'arm64' process: if that happens we are running unemulated but
debugserver will refuse to work.
The Go specification says that the result of division of untyped
constants should be an untyped integer constant if both constants are
untyped integers, the go/constant package however does something
different by always producing an untyped floating constant.
Fixes#3793
Go 1.23 and earlier does not take into account that Mach-O section
names are limited to 16 characters, which causes DWARF sections with
long names to be truncated and become unreadable.
Fixes#3797
* terminal/starbind: fix starlark conversion of named consts
If a value of a derived integer type matches a named constant,
Delve will wrap the string representation of the value with
the name of the constant, causing ParseInt/ParseUint to fail.
This change removes the wrapping before attempting to parse
the value before sending it to Starlark.
* terminal: add starlark tests for enums
TestRangeOverFuncNext and TestRangeOverFuncNextInlined are failing on
linux/386 with go1.23 due to an inconsistency on how append works on
32bit platforms.
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.
Move all tests of the functionality of proc.next,
proc.(*TargetGroup).Next, proc.(*TargetGroup).Step,
proc.(*TargetGroup).StepOut to their own test file.
Add 1.23 to supported versions and to test matrix, remove 1.19 and 1.20
from supported versions (1.19 should have been removed long ago, but we
forgot to do it on release).
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
We are already importing v3 indirectly for github.com/spf13/cobra/doc,
update our own dependency to v3 as well so that we can delete one
module from the vendor directory.
