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
We used to autoremove the trace recorded by rr but as a result of
various refactorings done to implement follow exec mode this broke.
Restore the functionality.
Also remove the _fixtures/testfnpos.go file which is autogenerated
during testing.
With the glibc loader the link map entry for the static executable has
an empty name field and address equal to 0x0. This case was already
handled by the check in bininfo.go AddImage for names to be valid
paths.
With the musl loader however the first entry, corresponding to the
static executable, has a valid path with address equal to 0x0, since we
record a real address for the image corresponding to the static
executable this results in having two entries for the executable when
musl is used to link go programs.
Change the code scanning the debug link map so that the first entry is
skipped if it has address equal to zero.
Fixes#3617
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.
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
Change VersionAfterOrEqual(x, A, B) to return true for pre-releases of
version A.B. This is what it did before, it was broken when goversion
was changed to support the new version format.
* 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
This allows us to update this dependency on our schedule which is important because the module relies on manually updating the known list of Go versions to function correctly. Forking allows us to keep this up to date ourselves and possibly create a new system to prevent having to perform this manual step in the future.
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.
When using debugserver as a backend a manual stop request can end up
looking like an hardcoded breakpoint if the thread that receives the
stop request happens to be stopped right after a hardcoded breakpoint
(and the space between functions is filled with hardcoded breakpoints).
When creating hardcoded breakpoints we should ignore the trapthread if
a manual stop has been requested.
This problem made TestSetBreakpointWhileRunning and
TestSetFunctionBreakpointWhileRunning fail on macOS between 1.7% and 6%
of the time.
TestIssue1376 in rr_test.go used to pass accidentally, the stop when
the start of the recording was reached was mistaken for a hardcoded
breakpoint.
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.
The gdb remote serial protocol returns in several places a list of key
value pair in the form key1:value1;key2:value2;...;keyN:valueN.
We had ad-hoc parsers for this in three places, this commit
consolidates the parser in a single utility object.
Instead of having a different version for each architecture have a
single version that uses an architecture specific list of registers.
Also generalize it so that, if we want, we can extend the workaround to
other runtime functions we might want to call (for example the channel
send/receive functions).
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.
Issue #3548 describes a bug in the compiler which was fixed by commit
505e50b. But this case wasn't covered by our current tests (obviously)
and the fix in the compiler looks accidental so it's worth adding a
test for it.
Fixes#3548
This patch adds support for listing and setting breakpoints on inlined functions within stripped binaries. It uses a forked version of `debug/gosym` copied from golang.org/x/vuln/internal/vulncheck/internal/gosym which adds support for parsing the inline tree of the pclntab section. Parsing this section requires knowing the offset of the "go:func.*" symbol, which is not present in stripped binaries via the ``.symtab` section so instead, we search the `.noptrdata` section which contains `runtime.moduledatap` which contains the value of that missing symbol, which we then can use to find the inline tree for a given function.
Given all this we parse the inline tree for each function we find, and then add that information the the appropriate `Function` contained in `bi.Functions`, using a relatively empty `Function` struct as what would be the abstract origin.
- fix TestRefreshCurThreadSelGAfterContinueOnceError and TestBadAccess
to work when debugserver has --unmask-signals
- when a fatal signal is received while singlestepping delay its
delivery until the subsequent continue, otherwise debugserver will get
stuck completely (fixes TestNilPtrDerefInBreakInstr)
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.
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>
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
TestStacktraceGoroutine failed intermittently on freebsd/amd64/go1.20.
This happens because of two windows, in the scheduler (right after
parking a goroutine and just before resuming a parked goroutine) where
a thread is associated with a goroutine but running in the system stack
and there is no systemstack_switch frame to connect the two stacks.
Go1.22 switched to emitting PIE by default and also changed some
details of the PIE implementation. This breaks delve entirely on macOS.
Fix how relocations are handled on macOS.
Update test matrix to remove 1.18 and add 1.21, fix build scripts to
deal with the new format returned by:
https://golang.org/VERSION?m=text
which now has an extra second line with the time.
Adds a waitfor option to 'dlv attach' that waits for a process with a
name starting with a given prefix to appear before attaching to it.
Debugserver on macOS does not support follow-fork mode, but has this
feature instead which is not the same thing but still helps with
multiprocess debugging somewhat.
I searched the source code of Go, and found no usages of
"== (reflect.Value{})" and "!= (reflect.Value{})". I think
it's more idiomatic to use "IsValid" to check a zero Value.
Change FindLocation so it can return a substitute location expression
and propagate it to pkg/terminal/command.
When breakpoints are set using the syntax :<lineno> or +<lineno>
produce a substitute location expression that doesn't depend on having
a valid scope and can be used to restore the breakpoint.
Fixes#3423
Show the location expression that will be used to set a suspended
breakpoint in the breakpoints list.
Also change 'target' called without arguments to print a better error
message and 'target follow-exec' without the last argument to print the
state of follow-exec.
