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
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.
There is no benefit to having a small part of the freebsd backend
implemented in C, rather than using cgo. While here, add a missing
call to procstat_close and check the return value of
procstat_getpathname.
With recent changes to debian/ubuntu tzdata package, the Mexico/BajaSur is not valid anymore (not present by default). It is now present in the tzdata-legacy package, which is not a essential package. Without this timezone, the call to time.LoadLocation() will send a nil location, which will provoke a panic in time.ParseInLocation(). This change uses the underlying associated timezone America/Mazatlan.
Fixes bugs introduced in v1.21.1
* Avoid dropping the last bytes from stderr/stdout when Read returns an
error. (Read returns n>0). And skip sending Output event if Read
returns n==0.
* Fix the bug that drops all stdout in the existing noDebug mode.
For #3253
Thank you to everyone who contributed to this release:
@alexsaezm, @pgavlin, @archanaravindar, @aarzilli, @hyangah, @thechampagne, @javierhonduco, @andreimatei, @gocurr, @alexandear, @stefanhaller.
* enable func call injection on delve for ppc64le
* Function call injection on Delve/ppc64le, modified DWARF encoding and decoding for floating point registers to make floatsum test work
* Function call injection on Delve/ppc64le cleanup
* skip PIE tests for function call injection on other packages
* Address review comments
* accounted for additional skipped PIE tests for function call injection
* Code cleanup and undoing revert of previous commit
* Enable function call injection only on 1.22 and above and some cleanup
* additional cleanup, go fmt run
* Debug function call tests fail on ppc64le/PIE mode adjusted the backup_test_health.md file accordingly
The current implementation assumes a specific command line interface
for opening an editor at a specific location within the source file.
This patch updates for different formats, namely the one used by the
editor 'hx'.
* 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.
This command lists the packages included in the debugee.
The implementation utilizes "ListPackagesBuildInfo" RPC.
In order to support server-side filtering like `sources` and other
commands, expanded the ListPackagesBuildInfo RPC to take an optional
filter field.
From the Go specification:
"1. For a nil slice, the number of iterations is 0." [1]
Therefore, an additional nil check for before the loop is unnecessary.
[1]: https://go.dev/ref/spec#For_range
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
This solves the problem that function names with long package paths are hard to
read when the callstack window is narrow, because all you see is the beginning
of the package path.
For example, instead of
github.com/some/long/package/path/pkg.(*SomeType).SomeMethod
we now display
pkg.(*SomeType).SomeMethod
Miscellaneous non-functional changes to prepare for adding support for
follow-exec mode on Windows:
- removed (*nativeProcess).wait function from Windows backend (unused).
- move close of ptraceDoneChan from release to handlePtraceFuncs, this
makes postExit callable by a function executed by execPtraceFunc.
- change addTarget to detach before creating the target object if we
don't actually want to attach to the child process, also moved the
detach call to (*processGroup).add instead of having one in addTarget
and one in the code that calls (*processGroup).add.
- changed Detach to be a method of TargetGroup/ProcessGroup, the
Windows backend will need access to the process group to call
WaitForDebugEvent.
- moved resume method to processGroup. First all threads stopped at a
breakpoint need to be stepped, then all other threads can be resumed.
This is true also for linux even though it didn't cause the current
tests to fail.
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.
Implementing the `DW_CFA_remember_state` and `DW_CFA_restore_state`
according to the DWARF specification requires us to create a stack that
can store an arbitrary number of elements, that is, there could be
multiple "pushes" before "popping" them.
From the 5th revision of the spec [0]:
> 6.4.2.4 Row State Instructions
> DW_CFA_remember_state
> The DW_CFA_remember_state instruction takes no operands. The required
> action is to push the set of rules for every register onto an implicit stack.
> DW_CFA_restore_state
> DW_CFA_restore_state
> The DW_CFA_restore_state instruction takes no operands. The required action
> is to pop the set of rules off the implicit stack and place them in the
> current row.
- [0]: https://dwarfstd.org/doc/DWARF5.pdf
Signed-off-by: Francisco Javier Honduvilla Coto <javierhonduco@gmail.com>
- add architecture rule for ppc64le so that incompatible agents don't
pick up the build
- disable PIE tests on linux/ppc64le (the tests claim it doesn't work)
- enable PIE tests on darwin/amd64 now that the entry point calculation
has been fixed
- remove dependency on wget and curl in the test script for linux to
reduce test time
- only install git in the linux test script when we need it
- remove staticcheck from linux/ppc64le builds (it takes almost 5
minutes between installation and execution and makes the test timeout
sometimes)
- drop windows/arm64/tip build, the windows/arm64 build is broken
anyway and since there is only one agent it makes CI runs slow
- drop linux/ppc64le/tip build, there is only one agent, it's slow and
it will always timeout. CI runs in excess of 1h are too long.
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
Add parsing for the new version format with toolchain (X.Y.Z-something)
and simplify internal representation of versions so that revision, beta
version and rc version are all represented on a single field with rc
and beta versions being negative numbers (this limits rc versions to a
maximum of 1000 which will not be a problem in practice).
The -C argument must come first on the command line of 'go build' if
the flags specified by the user via build-flags start with -C pass it
first.
Replaces #3380
