12 Commits

Author SHA1 Message Date
a80904ca1f proc: do not always allocate struct literals (#3953)
Do not always allocate new struct literals to the target's memroy. Wait
until they actually need to have an address.

Fixes #1465
2025-03-24 10:24:49 -07:00
18ce5d6baa proc: add support for struct literals (#3935)
* 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
2025-03-18 10:11:05 -07:00
6ef45f534c proc: expose breakpoint hitcounts in expressions (#3874)
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.
2025-03-05 12:39:47 -08:00
2685a42bc0 proc: do not pin function call returns for toplevel call (#3925)
For the toplevel function call do not perform pinning since the
function results are unpinned immediately.
2025-03-05 08:58:01 -08:00
025d47c6e9 proc: adds pointer pinning to call injection (#3787)
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
2024-10-04 10:44:57 -07:00
abad6bb97e proc: use .closureptr for stepping through range-over-func statements (#3763)
* 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
2024-07-11 10:26:38 -07:00
4b628b81cb proc: refactor identifier evaluation for range-over-func support (#3738)
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
2024-06-14 14:36:11 -07:00
64a46abd81 proc: generalize escapeCheck and allocString (#3687)
* 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
2024-04-19 08:44:47 -07:00
6cd0b70b30 proc: if a reslice operator is used load the whole slice (#3623)
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
2024-01-24 09:21:59 -08:00
1e2338d233 proc: allow evaluator to reference previous frames (#3534)
Fixes #3515
2023-10-24 18:57:39 +02:00
0761d37c53 proc: fix comment typos (#3531) 2023-10-19 11:04:31 -07:00
2c700230de proc: use stack machine to evaluate expressions (#3508)
* 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
2023-10-17 11:21:59 -07:00