The DWARF standard does not say that a DW_ATTR_abstract_origin can only
reference entries that appear before it, this change fixes BinaryInfo
to comply. See #2284 for an example of this happening.
Changs TestClientServer_FullStacktrace and
Test1ClientServer_FullStacktrace to log more information, also removes
code from TestFrameEvaluation that could mask the error.
Updates #2231
* add -json flag when running tests on TeamCity
* introduce TeamCity builds
* restore gdbserial constants for 386
Otherwise compilation fails.
* skip TestAttachRequest on Windows as it never finishes
* run tests on 1.16beta1
* proc: misc test fixes for Go 1.16
* proc: fix cgo stacktraces in Go 1.16 with simplified C -> Go call path
* dwarf/line: make dwarf/line correct when '\\' are used
Our code depends heavily on paths being '/' separated because go always
produced '/' separated file paths. The call to filepath.Join will
normalize the paths, on windows, to always be '\\' separated, which
violated our assumptions.
This didn't use to be a problem because the codepath that calls
filepath.Join was never exercised by executable files produced by Go,
but Go 1.16 started producing debug_line sections that use the
directory table with https://go-review.googlesource.com/c/go/+/263017/.
Fix this to always use path.Join after making sure, on windows, to
always normalize paths to use '/' as a separator. Replace the use of
filepath.IsAbs with an operating system independent version.
* goversion: bump supported Go version
If a thread exits while we are looking at it just treat it as if the
status had reported it as exited instead of doing something special.
Fixes flakiness in TestIssue387.
Fix bug in DAP test: TestEvaluateCallRequest.
In Go 1.15 the call injection will be executed on a different goroutine
from the goroutine where it was started on to avoid confusing the
garbage collector, the test must be aware of this fact and use the
goroutine ID from the stopped response instead of assuming 1 is the
currently selected goroutine.
Disables TestAttachDetach when running in Github Actions.
Disable some coredump tests when running in Github Actions (core size
limits?).
The comment on the advanceRegs() method was referencing several
nonexistent fields. This patch fixes that, and improves the comment to
reference the peculiar interaction between the method and it.regs.
evalFunctionCall needs to remove the breakpoint from the current thread
after starting the function call injection, otherwise Continue will
think that the thread is stopped at a breakpoint and return to the user
instead of continuing the call injection.
Adds a flag that distinguishes the return values of an injected
function call from the return values of a function call executed by the
target program.
This is needed to fix the problem we have with 1.15.4+ after the
backport is applied to it. The DWARF standard isn't clear on what
should happen with the end_of_sequence opcode but this is consistent
with debug/dwarf.LineReader as well as gdb.
* Use the active xcode-select path instead of a hardcoded Xcode path
* Refactored exec.Command to invoke Output instead of running with a custom buffer for stdout
Addresses review comment by @derekparker
1. Forward stdin/stdout/stderr to the target process when in foreground
mode instead of always forwarding the current tty (issue #1964)
2. When redirecting a file descriptor make sure to also specify
something for all three otherwise debugserver will misbehave (either
exit on launch or run but giving the target process a closed file
descriptor).
Fixes#1964
On linux we can not read memory if the thread we use to do it is
occupied doing certain system calls. The exact conditions when this
happens have never been clear.
This problem was worked around by using the Blocked method which
recognized the most common circumstances where this would happen.
However this is a hack: Blocked returning true doesn't mean that the
problem will manifest and Blocked returning false doesn't necessarily
mean the problem will not manifest. A side effect of this is issue
#2151 where sometimes we can't read the memory of a thread and find its
associated goroutine.
This commit fixes this problem by always reading memory using a thread
we know to be good for this, specifically the one returned by
ContinueOnce. In particular the changes are as follows:
1. Remove (ProcessInternal).CurrentThread and
(ProcessInternal).SetCurrentThread, the "current thread" becomes a
field of Target, CurrentThread becomes a (*Target) method and
(*Target).SwitchThread basically just sets a field Target.
2. The backends keep track of their own internal idea of what the
current thread is, to use it to read memory, this is the thread they
return from ContinueOnce as trapthread
3. The current thread in the backend and the current thread in Target
only ever get synchronized in two places: when the backend creates a
Target object the currentThread field of Target is initialized with the
backend's current thread and when (*Target).Restart gets called (when a
recording is rewound the currentThread used by Target might not exist
anymore).
4. We remove the MemoryReadWriter interface embedded in Thread and
instead add a Memory method to Process that returns a MemoryReadWriter.
The backends will return something here that will read memory using
the current thread saved by the backend.
5. The Thread.Blocked method is removed
One possible problem with this change is processes that have threads
with different memory maps. As far as I can determine this could happen
on old versions of linux but this option was removed in linux 2.5.
Fixes#2151
TestStepConcurrentDirect will occasionally fail (7% of the time on my
setup) by either causing the target processs to execute an invalid
instruction or (more infrequently) by switching to the wrong thread.
Both of those are caused by receiving SIGTRAPs for threads hitting a
breakpoint after it has been removed (the thread hits the breakpoint,
we stop everything and remove the breakpoint and only after we receive
the signal).
Change native.(*nativeProcess).stop to handle SIGTRAPs that can't be
attributed to a breakpoint, a hardcoded breakpoint in the program's
text, or manual stops (and therefore are likely caused by phantom
breakpoint hits).
Co-authored-by: a <a@kra>
* service/rpccommon: log error for conns rejected by --only-same-user
If no logger is enabled manually write to stderr instead.
Fixes#2209
* logflags: fix style complaints from DeepSource
Due to a missing check TestCgoStacktrace2 didn't actually check
anything. Enable it and then skip it on linux/386 and linux/arm64 where
it's broken.
Co-authored-by: a <a@kra>
If the process receives a signal (or sends a singal to itself) and then
dies before we can route the signal back to it we still need to
retrieve its exit status.
Fixes a rare failure of TestIssue1101 in proc_test.go
Co-authored-by: a <a@kra>
* proc/tests: keep track of tests skipped due to backend problems
Mark tests skipped due to backend problems and add a script to keep
track of them.
* Travis-CI: add ignorechecksum option to chocolatey command
Looks like a configuration problem on chocolatey's end.
* proc: use argument position for addr only when injecting function calls
We can not, in general, use the argument position to determine the
address of a formal parameter, it will not work in presence of
optimizations or inlining. In those cases formal arguments could be
stored in registers.
Fixes#2176
* Travis-CI: add ignorechecksum option to chocolatey command
Looks like a configuration problem on chocolatey's end.
Co-authored-by: a <a@kra>
* dwarf/line: ignore end_of_sequence entry if AllPCsBetween
Go 1.15 (but possibly prior versions of Go too) has a tendency to use
an address in the middle of an instruction for this entry, but if it
was correct it would be after the last instruction of the function
anyway.
This problem manifests especially frequently as a target crash in
TestStepConcurrentPtr on linux/arm64 (~6% of the runs).
* Travis-CI: add ignorechecksum option to chocolatey command
Looks like a configuration problem on chocolatey's end.
Co-authored-by: a <a@kra>
* Revert "proc: Find executable should follow symbol links."
This reverts commit 3e04ad0fada0c3ab57caf58bc024e4c0f9a3e01a.
* proc: resolve symlinks when searching for split debug_info if path is /proc/pid/exe
Fixes#2168
During the testing of the core dump generation feature two bugs were
discovered in gdbserial:
1. we don't check that both bytes of the checksum are read, if the
buffer only has one byte we can end up reading only one byte instead
of two and the second byte will mess up the parsing of the next
packet
2. binary encoded packets can start with an 'E' and not be errors, when
using binary responses add an extra check for the lenght of the
response before deciding that the response is an error.
Unfortunately this encoding is inherently ambiguous (we can't
distinguish a 3 byte response starting with 'E' from an error) so
binary requests that lead to short responses should be avoided.
Testing this is complicated, they will be tested implicitly by the
upcoming core dump test.
Co-authored-by: a <a@kra>
Since proc is supposed to work independently from the target
architecture it shouldn't use architecture-dependent types, like
uintptr. For example when reading a 64bit core file on a 32bit
architecture, uintptr will be 32bit but the addresses proc needs to
represent will be 64bit.
Adds features to support default file descriptor redirects for the
target process:
1. A new command line flag '--redirect' and '-r' are added to specify
file redirects for the target process
2. New syntax is added to the 'restart' command to specify file
redirects.
3. Interactive instances will check if stdin/stdout and stderr are
terminals and print a helpful error message if they aren't.
An internal breakpoint condition shouldn't ever error:
* use a ThreadContext to evaluate conditions if a goroutine isn't
available
* evaluate runtime.curg to a fake g variable containing only
`goid == 0` when there is no current goroutine
Fixes#2113
Recent changes to the way registers are handled broke reporting of AVX
registers (i.e. YMMx). This change restores the functionality by:
- concatenating the higher half of the YMMx registers to their
corresponding XMMx lower half (YMMx registers do not have an
independent DWARF register number)
- modifying the formatSSEReg function to handle them when they are
present.
Fixes#2033
Commit 1ee8d5c reviewed in Pull Request #1960 relaxed some tests using
goroutinestackprog but missed others.
Fixes some test flakiness that isn't relevant.
* proc: start variable visibility one line after their decl line
In most cases variables shouldn't be visible on their declaration line
because they won't be initialized there.
Function arguments are treated as an exception.
This fix is only applied to programs compiled with Go 1.15 or later as
previous versions of Go did not report the correct declaration line for
variables captured by closures.
Fixes#1134
* proc: silence go vet error
* Makefile: enable PIE tests on windows/Go 1.15
* core: support core files for PIEs on windows
* goversion: add Go 1.15 to supported versions
* proc: fix function call injection for Go 1.15
Go 1.15 changed the call injection protocol so that the runtime will
execute the injected call on a different (new) goroutine.
This commit changes the function call support in delve to:
1. correctly track down the call injection state after the runtime
switches to a different goroutine.
2. correctly perform the escapeCheck when stack values can come from
multiple goroutine stacks.
* proc: miscellaneous fixed for call injection under macOS with go 1.15
- create copy of SP in debugCallAXCompleteCall case because the code
used to assume that regs doesn't change
- fix automatic address calculation for function arguments when an
argument has a spurious DW_OP_piece at entry
The file:line information for the entrypoint is more acccurate than the
file:line information at a return point, which could be affected by a
compiler bug.
Fixes#2086
Recent change #2061:
292f5c69f0c769fd32c2e8b1e7153b56e908efd7
proc: step into unexported runtime funcs when already inside runtime
means that TestIssue414 (which tries to step repeatedly until the
program exits) can now steps through way more runtime code than it ever
did before. This causes this test to occasionally fail. Stepping
blindly through runtime code has never been particularly safe as the
runtime can switch to a different goroutine causing Delve to misbehave.
This change restores the previous behavior of TestIssue414 where Step
behaved like Next inside runtime code.
These methods only work if registers have been loaded once after the
last resume, there's probably no code path that calls SetXX before
Thread.Registers but lets make sure it can't happen anyway.
On platforms other than macOS this doesn't matter but on macOS a
segmentation fault will cause ContinueOnce to return an error, before
returning it we should still fix the current thread and selected
goroutine values.
Fixes#2078
* terminal/command: Add 'reload' command
These changes add the 'reload' command, which allows us to rebuild the project
and start the debugging session again. Currently, if the project's code is
updated while debugging it, Delve shows the new source code, but it's still
running the old one. With 'reload', the whole binary is rebuilt, and the
process starts again.
Fixes#1551
* Remove unnecessary print
Changes to be committed:
modified: pkg/terminal/command.go
* Add tests and refactor the code
Changes to be committed:
modified: cmd/dlv/cmds/commands.go
modified: go.mod
modified: pkg/terminal/command.go
modified: service/config.go
modified: service/debugger/debugger.go
modified: service/test/integration2_test.go
* Fix typo in the comment
Changes to be committed:
modified: service/debugger/debugger.go
* Fix typo in the name of the variables
The variables are local therefore the capitalization is not needed
Changes to be committed:
modified: cmd/dlv/cmds/commands.go
* Call GoTestBuild
Also, remove the := to avoid redeclaration
* Change the Kind in the tests
Change from debugger.ExecutingGeneratedTest to
debugger.ExecutingGeneratedFile for consistency.
We are generating a real binary instead of a test
one so ExecutingGeneratedFile makes more sense here.
Changes to be committed:
modified: service/test/integration2_test.go
* Avoid breakpoints based on addresses
Changes to be committed:
modified: service/debugger/debugger.go
* Update the rebuild behaviour
There are a few cases where we can't rebuild the binary because we don't
know how it was build.
Changes to be committed:
modified: service/debugger/debugger.go
* Fix typos and update documentation
Changes to be committed:
modified: Documentation/cli/README.md
modified: pkg/terminal/command.go
modified: service/config.go
modified: service/debugger/debugger.go
* Fix typo
* Remove variables
They were added to the debugger.Config
* Rename variable
Rename Kind to ExecuteKind to make it more accurate
Changes to be committed:
modified: cmd/dlv/cmds/commands.go
modified: service/debugger/debugger.go
modified: service/test/integration2_test.go
Normally we don't step into unexported runtime functions because the
compiler is free to insert them into the code and they are not relevant
to the user, however if we are already stepping through a runtime
function we should let step into work normally and step into other
runtime functions.
This issue causes a failure of TestTracePid that was observed in CI:
https://travis-ci.com/github/go-delve/delve/jobs/343053383
I'm not sure what causes it in this particular instance but there are
several ways in which a thread stopped at a breakpoint might have a
BreakpointInfo == nil field (see variable withBreakpointInfo in
debugger.Debugger.Command).
Changes implementations of proc.Registers interface and the
op.DwarfRegisters struct so that floating point registers can be loaded
only when they are needed.
Removes the floatingPoint parameter from proc.Thread.Registers.
This accomplishes three things:
1. it simplifies the proc.Thread.Registers interface
2. it makes it impossible to accidentally create a broken set of saved
registers or of op.DwarfRegisters by accidentally calling
Registers(false)
3. it improves general performance of Delve by avoiding to load
floating point registers as much as possible
Floating point registers are loaded under two circumstances:
1. When the Slice method is called with floatingPoint == true
2. When the Copy method is called
Benchmark before:
BenchmarkConditionalBreakpoints-4 1 4327350142 ns/op
Benchmark after:
BenchmarkConditionalBreakpoints-4 1 3852642917 ns/op
Updates #1549
* cmd/dlv,debugger: Improve dlv trace and trace command output
This patch improves the `dlv trace` subcommand output by reducing the
noise that is generated and providing clearer more concise information.
Also adds new tests closing a gap in our testing (we previously never
really tested this subcommand).
This patch also fixes the `dlv trace` REPL command to behave like the
subcommand in certain situations. If the tracepoint is for a function,
we now show function arguements and return values properly.
Also makes the overall output of the trace subcommand clearer.
Fixes#2027
The option is "source-list-line-count". It defaults to 5, which was previously
hardcoded in printfile(), but now you can change it dynamically, for instance:
$ config source-list-line-count 20
$ list
When trying to compile tests in a package that does not contain tests
'go' emits an error message on stdout instead of stderr. Let the 'go'
command write to stdout too.
Fixes#2042
Unexport `GetDebugServerAbsolutePath` and avoid unnecessary repeated calls.
Remove `os.Stat` because `Exec.LookPath` has already used `os.Stat`.And Fix
some comments.
When there is a single piece and it's a register value just return it.
This is important for clang compiled programs which will use DW_OP_regN
to specify the value of the frame base.
