If we have an error in funcCallStep we must not mark the function call
as finished, otherwise the error will be discarded and execution will
continue under the assumption that there was no error.
Fixes#4085
Type casts between slice types with the same element type should be
allowed. In theory this should be allowed by the check on the real type
(which already gets rid of typedefs) but the compiler here actually
creates a distinct type for Message instead of having it as a typedef
for []uint8.
Fixes#4042
Variables normally become visible on the line after the one they are
defined at, because on their definition line they will not be
initialized. This is a problem for variables captured by closures
because they get the closure function's first line as the declaration
line.
Make variables captured by closures visible on their declaration line
and load their value from the closure struct if they are unreadable.
Fixes#4000
Fill the bi field of constant variables when we create them. This is
meant to address #4021 which is caused by trying to access a member
field of a variable with a nil bi. I couldn't find a way to make a
constant reach that point into the code but this still looks like the
most likely explanation.
Fixes#4021
The dwarfToRuntimeType does basically the same thing in another way and
doesn't have a bug with making unsigned comparisons that should be
signed. It also does more things compared to dieToRuntimeType but it
shouldn't matter since function call injection is very slow anyway.
Fixes an intermittent bug on windows:
https://delve.teamcity.com/buildConfiguration/Delve_windows_amd64_1_24/67152
* service/test: fix compile error in tests
Due to a merge conflict the tests in service/test are not compiling.
* proc: add support for struct literals
Adds support for evaluating struct literals, and allocating them into
the target's memory.
Updates #1465
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.
* 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
After a call injection sequence terminates allow the evaluator to
access thread registers again so that variables stored in registers can
be used as arguments.
Fixes#3310
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
* 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
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
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
* proc: generalize escapeCheck and allocString
Generalizes the function for checking for escaping pointers so that it
can be used to iterate on all pointers of a variable.
Also generalizes the string allocation opcodes so that in the future we
can use it to call other special runtime functions (for example: map
access, channel send/receive, etc).
* review changes
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.
When the users uses a reslice operation load the whole resliced
variable, ignoring the MaxArrayValues setting.
Only apply this when the 'high' part is specified and a literal and the
'low' part is either unspecified or a literal.
Fixes#3600
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.
* proc: make some type casts less counterintuitive
The interaction of type casts with load configuration is sometimes
counterintuitive. This commit changes the way it is performed so that
when converting slices to strings and vice versa the maximum size
corresponding to the target type is used (i.e. MaxStringLen when
converting slices to strings and MaxArrayValues when converting slices
to strings).
This doesn't fully solve the problem (conversions to []rune are
problematic and multiple chained type casts will still be confusing)
but removes the problem for the majority of practical uses.
Fixes#3595, #3539
We have used a goroutine to keep track of some of the expression
evaluation status across target resumes during call injections.
Now that the expression interpreter has been rewritten to use a stack
machine we can move what little state is left into the stack machine
and get rid of the goroutine-and-channel mechanism.
* proc: use stack machine to evaluate expressions
This commit splits expression evaluation into two parts. The first part (in
pkg/proc/evalop/evalcompile.go) "compiles" as ast.Expr into a list of
instructions (defined in pkg/proc/evalop/ops.go) for a stack machine
(defined by `proc.(*evalStack)`).
The second part is a stack machine (implemented by `proc.(*EvalScope).eval`
and `proc.(*EvalScope).evalOne`) that has two modes of operation: in the
main mode it executes inteructions from the list (by calling `evalOne`), in
the second mode it executes the call injection protocol by calling
`funcCallStep` repeatedly until it either the protocol finishes, needs more
input from the stack machine (to set call arguments) or fails.
This approach has several benefits:
- it is now possible to remove the goroutine we use to evaluate expression
and the channel used to communicate with the Continue loop.
- every time we resume the target to execute the call injection protocol we
need to update several local variables to match the changed state of the
target, this is now done at the top level of the evaluation loop instead of
being hidden inside a recurisive evaluator
- using runtime.Pin to pin addresses returned by an injected call would
allow us to use a more natural evaluation order for function calls, which
would solve some bugs #3310, allow users to inspect values returned by a
call injection #1599 and allow implementing some other features #1465. Doing
this with the recursive evaluator, while keeping backwards compatibility
with versions of Go that do not have runtime.Pin is very hard. However after
this change we can simply conditionally change how compileFunctionCall works
and add some opcodes.
* review round 1
* review round 2
* 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.
Adds -chan option to the goroutines command to list only the goroutines
running on a specified channel.
Also when printing a variable if it is a channel also print the list of
goroutines that are waiting on it.
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.
The compiler produces ABI compatibility wrappers for some functions.
We have changed the support for breakpoints to allow a single logical
breakpoint to correspond to multiple physical breakpoints, take
advantage of that to set breakpoints on both the ABI wrapper and the
real function.
Fixes#3296
This patch changes how we handle end_seq in the debug_line state machine
program. Instead of always considering the state machine invalid at the
end_seq instead simply consider the *current* address invalid. This
solves a number of issues such as incorrect disassemble output for the
last few instructions in certain functions, and creating an eval scope
at an address within the last few instructions of certain functions. It
also handles the case where the end_seq address is the same as the start
address of the next adjacent function, which would previously confuse
Delve which is why we initially marked end_seq as invalid for the entire
state machine. This approach is more nuanced and still solves that
initial problem while fixing some problems introduced by that patch.
Fixes a bug where we cannot get locals (including arguments and return
values) from a given scope because the line number state machine ends up
in an invalid state because of this parameter being set to false.
* proc: add a test for dangling unsafe pointers
This new tests checks the behavior when dereferencing dangling pointers.
The behavior does not fully make sense; the test checks the current
behavior for now, which will be improved in subsequent commits.
* proc: populate pointer values
This patch changes how Value and Unreadable are populated for pointer
Variables. Before this patch, variables of kind reflect.Ptr did not have
their Value field populated. This patch populates it in
Variable.loadValue(), which seems natural and consistent with other
types of variables. The Value is the address that the pointer points to.
The Unreadable field was populated inconsistently for pointer variables:
it was never populated for an outer pointer, but it could be populated
for an inner pointer in pointer-to-pointer types. Before this patch,
in pointer whose value could not be read was not easily distinguishable
from a pointer with a value that could be read, but that cannot be
dereferenced (i.e. a dangling pointer): neither of these would be marked
as Unreadable, and both would have a child marked as Unreadable. This
patch makes it so that a pointer variable whose pointer value cannot be
read is marked as Unreadable.
Using this new distinction, this patch fixes a bug around dereferencing
dangling pointers: before, attempting such a dereference produced a
"nil pointer dereference" error. This was bogus, since the pointer was
not nil. Now, we are more discerning and generate a different error.
* proc: allow casts form unsafe.Pointer to any pointer and vice versa
We've allowed doing this with uintptr but we should allow
unsafe.Pointer to be used like Go uses it.
* proc: fix type casts to ptr-to-ptr types
Fix type casts to **type.
Go 1.20 switched to uint64 to represent goroutine IDs, we can't
actually follow suit because we have allowed clients to use -1 to refer
to the currently selected goroutine, however we should at least switch
to int64 and also update the rtype check to accept the 1.20 type.
