This flag allows users on UNIX systems to set the tty for the program
being debugged by Delve. This is useful for debugging command line
applications which need access to their own TTY, and also for
controlling the output of the debugged programs so that IDEs may open a
dedicated terminal to show the output for the process.
* gdbserial/gdbserver: Dynamically resolve debugserver binary
Instead of hardcoding the absolute path to the Command Line
Tools (CLT) binary, will attempt to resolve the path at the
$PATH, or at the Xcode bundle. If none are available, will
fallback to the default CLT location.
Fixes#986
* gdbserial/gdbserver: Log outgoing executed commands
Add logging to capture the executable and associated arguments used
in LLDBLaunch and LLDBAttach
Related to #986
* gdbserial/gdbserver: Add unit tests for helper function
Define unit tests for helper function. Setup each test to temporarily make
PATH variable, and file system changes, and subsequently revert them.
Related to #986
* gdbserial/gdbserver: Lazily load function
Lazily obtain absolute path to avoid increasing load times.
Remove flaky tests.
Related to #986
The test was always flaky because we can't fully control the state of
all goroutines in the target program, Go 1.14's asynchronous preemption
exacerbates the problem.
See for example:
https://travis-ci.com/github/go-delve/delve/jobs/302407282
This commit relaxes the checks made by the test to avoid irrelevante
flakiness.
Under some circumstances (methods with non-pointer receivers or from
embedded fields called through an interface) the compiler will
autogenerate wrapper functions.
This commit changes next, step and stepout to skip all autogenerated
wrappers.
Fixes#1908
Allows Delve clients to stop a recording midway by sending a
Command('halt')
request.
This is implemented by changing debugger.New to start recording the
process on a separate goroutine while holding the processMutex locked.
By locking the processMutex we ensure that almost all RPC requests will
block until the recording is done, since we can not respond correctly
to any of them.
API calls that do not require manipulating or examining the target
process, such as "IsMulticlient", "SetApiVersion" and
"GetState(nowait=true)" will work while we are recording the process.
Two other internal changes are made to the API: both GetState and
Restart become asynchronous requests, like Command. Restart because
this way it can be interrupted by a StopRecording request if the
rerecord option is passed.
GetState because clients need a call that will block until the
recording is compelted and can also be interrupted with a
StopRecording.
Clients that are uninterested in allowing the user to stop a recording
can ignore this change, since eventually they will make a request to
Delve that will block until the recording is completed.
Clients that wish to support this feature must:
1. call GetState(nowait=false) after connecting to Delve, before any
call that would need to manipulate the target process
2. allow the user to send a StopRecording request during the initial
GetState call
3. allow the user to send a StopRecording request during any subsequent
Restart(rerecord=true) request (if supported).
Implements #1747
Reset the timer once we start executing the code paths we actually care
to measure, since the setup and continue steps can be relatively
expensive.
Also, disable recording on benchmarks. This seems less useful, and also
cuts out a lot of noise when benchmarks are run.
When switching to the goroutine stack the stack iterator registers
might not have any entry for the BP register, make sure to add it
instead of just trying to change it.
Instead of rescanning debug_info every time we want to read a function
(either to find inlined calls or its variables) cache the tree of
dwarf.Entry that we would generate and use that.
Benchmark before:
BenchmarkConditionalBreakpoints-4 1 5164689165 ns/op
Benchmark after:
BenchmarkConditionalBreakpoints-4 1 4817425836 ns/op
Updates #1549
Add logging for Issue #1927. The bug happens during the call to
api.ConvertThread, returning an error will not suffice since
ConvertThread will not surface it.
Updates #1927
Inserts a call to ClearAllGCache into stepInstructionOut so that cached
goroutine state is not inconsistent after an injected function call.\
Fixes#1925
If we call one expression which is the fake method of meanless
string, `delve` will panic. Strengthen the inspection of boundary
conditions when supporting function calls on non-struct types.
Update: #1871
* *: Fix go vet struct complaints
* *: Fix struct vet issue on linux
* *: Ignore proc/native in go vet check
We have to do some unsafe pointer manipulation that will never make go
vet happy within the proc/native package. Ignore it for runs of go vet.
* proc: move defer breakpoint code into a function
Moves the code that sets a breakpoint on the first deferred function,
used by both next and StepOut, to its function.
* proc: implement reverse step/next/stepout
When the direction of execution is reversed (on a recording) Step, Next and
StepOut will behave similarly to their forward version. However there are
some subtle interactions between their behavior, prologue skipping, deferred
calls and normal calls. Specifically:
- when stepping backwards we need to set a breakpoint on the first
instruction after each CALL instruction, once this breakpoint is reached we
need to execute a single StepInstruction operation to reverse step into the
CALL.
- to insure that the prologue is skipped reverse next needs to check if it
is on the first instruction after the prologue, and if it is behave like
reverse stepout.
- there is no reason to set breakpoints on deferred calls when reverse
nexting or reverse stepping out, they will never be hit.
- reverse step out should generally place its breakpoint on the CALL
instruction that created the current stack frame (which will be the CALL
instruction immediately preceding the instruction at the return address).
- reverse step out needs to treat panic calls and deferreturn calls
specially.
* service,terminal: implement reverse step, next, stepout
* proc,proc/*: move SelectedGoroutine to proc.Target, remove PostInitializationSetup
moves SelectedGoroutine, SwitchThread and SwitchGoroutine to
proc.Target, merges PostInitializationSetup with NewTarget.
* proc,proc/*: add StopReason field to Target
Adds a StopReason field to the Target object describing why the target
process is currently stopped. This will be useful for the DAP server
(which needs to report this reason in one of its requests) as well as
making pull request #1785 (reverse step) conformant to the new
architecture.
* proc: collect NewTarget arguments into a struct
Implement debugging function for 386 on linux with reference to AMD64.
There are a few remaining problems that need to be solved in another time.
1. The stacktrace of cgo are not exactly as expected.
2. Not implement `core` for now.
3. Not implement `call` for now. Can't not find `runtime·debugCallV1` or
similar function in $GOROOT/src/runtime/asm_386.s.
Update #20
* proc/native/linux: only set breakpoints on threads that receive SIGTRAP
* proc/native/linux: do not call (*Thread).Stopped inside (*Process).stop
(*Thread).Stopped is slow because it needs to open, read and parse a
file in /proc, we don't actually need to do that, we can just rely on
the value of Thread.os.running.
Benchmark before:
BenchmarkConditionalBreakpoints-4 1 12476166303 ns/op
Benchmark after:
BenchmarkConditionalBreakpoints-4 1 10403533675 ns/op
Conditional breakpoint evaluation: 1.24ms -> 1ms
Updates #1549
This change adds `ProcessVmRead` and `ProcessVmWrite` wrappers around
the syscalls `process_vm_readv` and `process_vm_writev`, available since
Linux 3.2. These follow the same permission model as `ptrace`, but they
don't actually require being attached, which means they can be called
directly from any thread in the debugger. They also use `iovec` to write
entire blocks at once, rather than having to peek/poke each `uintptr`.
These wrappers are used in `Thread.ReadMemory` and `WriteMemory`, still
falling back to `ptrace` if that fails for any reason. Notably,
`process_vm_writev` respects memory protection, so it can't modify
read-only memory like `ptrace`. This frequently occurs when writing
breakpoints in read-only `.text`, so to avoid a lot of wasted `EFAULT`
calls, we only try `process_vm_writev` for larger writes.
Adds an optional scope prefix to the `regs` command which allows
printing registers for any stack frame (as long as they were somehow
saved). Issue #1838 is not yet to be closed since we are still not
recovering the registers of a segfaulting frame.
Updates #1838
As we rearrange the code and the Go compiler changes the error message
returned by the compiler on unsupported architectures will change too,
making it un-googlable. Since the error message tends to be rather
obscure too this regularly confuses newbies.
This is an effort to make the error message for unsupported GOOS/GOARCH
combinations the same across all unsupported combinations and to make
it more user friendly.
Directories containing Go source code are supposed to contain a single
package. This property happens to be checked by cmd/go itself so it
will happen even before the syntax is fully checked and therefore has a
high probability of being the first (and only) error message being
print.
Here we take advantage of this by adding to the pkg/proc/native
directory a file with a bad package line that only gets compiled in on
unsupported GOOS/GOARCH combinations.
At present the error message for compiling Delve on unsupported systems
will be:
service/debugger/debugger.go:21:2: found packages native (proc.go) and your_operating_system_and_architecture_combination_is_not_supported_by_delve (support_sentinel.go) in $PATH_TO_DELVE/pkg/proc/native
Go 1.8 has been out of date for a while and the code to support it is
potentially dangerous if a future version of Go removes the runtime
types from debug_info and also changes their representation.
Removes the restriction that the DWARF type for the receiver of a method
must be a TypeDef. This seems reasonable in practice, but it turns out
Go DWARF does not consider
```
type X int
```
to be a typedef. This patch also allows for calling a method where the
receiver is not used or passed in, such as:
```
func (_ X) Method() { println("why") }
```
runtime.g is a large and growing struct, we only need a few fields.
Instead of using loadValue to load the full contents of g, cache its
memory and then only load the fields we care about.
Benchmark before:
BenchmarkConditionalBreakpoints-4 1 14586710018 ns/op
Benchmark after:
BenchmarkConditionalBreakpoints-4 1 12476166303 ns/op
Conditional breakpoint evaluation: 1.45ms -> 1.24ms
Updates #1549
Instead of reloading the registers for every thread every time the
process executes, reload the registers on demand for individual threads
and memoize the result.
The stacktrace code occasionally needs the value of g.m.g0.sched.sp to
switch stacks. Since this is only needed rarely and calling parseG is
relatively expensive we should delay doing it until we know it will be
needed.
Benchmark before:
BenchmarkConditionalBreakpoints-4 1 17326345671 ns/op
Benchmark after:
BenchmarkConditionalBreakpoints-4 1 15649407130 ns/op
Reduces conditional breakpoint latency from 1.7ms to 1.56ms.
Updates #1549
A significant amount of time is spent generating the string
representation for the proc.Registers object of each thread, since this
field is rarely used (only when the Registers API is called) it should
be generated on demand.
Also by changing the internal representation of proc.Register to be
closer to that of op.DwarfRegister it will help us implement #1838
(when Delve will need to be able to display the registers of an
internal frame, which we currently represent using op.DwarfRegister
objects).
Benchmark before:
BenchmarkConditionalBreakpoints-4 1 22292554301 ns/op
Benchmark after:
BenchmarkConditionalBreakpoints-4 1 17326345671 ns/op
Reduces conditional breakpoint latency from 2.2ms to 1.7ms.
Updates #1549, #1838
* tests: misc test fixes for go1.14
- math.go is now ambiguous due to changes to the go runtime so specify
that we mean our own math.go in _fixtures
- go list -m requires vendor-mode to be disabled so pass '-mod=' to it
in case user has GOFLAGS=-mod=vendor
- update version of go/packages, required to work with go 1.14 (and
executed go mod vendor)
- Increased goroutine migration in one development version of Go 1.14
revealed a problem with TestCheckpoints in command_test.go and
rr_test.go. The tests were always wrong because Restart(checkpoint)
doesn't change the current thread but we can't assume that when the
checkpoint was taken the current goroutine was running on the same
thread.
* goversion: update maximum supported version
* Makefile: disable testing lldb-server backend on linux with Go 1.14
There seems to be some incompatibility with lldb-server version 6.0.0
on linux and Go 1.14.
* proc/gdbserial: better handling of signals
- if multiple signals are received simultaneously propagate all of them to the
target threads instead of only one.
- debugserver will drop an interrupt request if a target thread simultaneously
receives a signal, handle this situation.
* dwarf/line: normalize backslashes for windows executables
Starting with Go 1.14 the compiler sometimes emits backslashes as well
as forward slashes in debug_line, normalize everything to / for
conformity with the behavior of previous versions.
* proc/native: partial support for Windows async preempt mechanism
See https://github.com/golang/go/issues/36494 for a description of why
full support for 1.14 under windows is problematic.
* proc/native: disable Go 1.14 async preemption on Windows
See https://github.com/golang/go/issues/36494
* pkg/proc: Introduce Target
* pkg/proc: Remove Common.fncallEnabled
Realistically we only block it on recorded backends.
* pkg/proc: Move fncallForG to Target
* pkg/proc: Remove CommonProcess
Remove final bit of functionality stored in CommonProcess and move it to
*Target.
* pkg/proc: Add SupportsFunctionCall to Target
* proc: separate amd64-arch code
separate amd64 code about stacktrace, so we can add arm64 stacktrace code.
* proc: implemente stacktrace of arm64
* delve now can use stack, frame commands on arm64-arch debug.
Co-authored-by: tykcd996 <tang.yuke@zte.com.cn>
Co-authored-by: hengwu0 <wu.heng@zte.com.cn>
* test: remove skip-code of stacktrace on arm64
* add LR DWARF register and remove skip-code for fixed tests
* proc: fix the Continue command after the hardcoded breakpoint on arm64
Arm64 use hardware breakpoint, and it will not set PC to the next instruction like amd64. We should move PC in both runtime.breakpoints and hardcoded breakpoints(probably cgo).
* proc: implement cgo stacktrace on arm64
* proc: combine amd64_stack.go and arm64_stack.go file
* proc: reorganize the stacktrace code
* move SwitchStack function arch-related
* fix Continue command after manual stop on arm64
* add timeout flag to make.go to enable infinite timeouts
Co-authored-by: aarzilli <alessandro.arzilli@gmail.com>
Co-authored-by: hengwu0 <wu.heng@zte.com.cn>
Co-authored-by: tykcd996 <56993522+tykcd996@users.noreply.github.com>
Co-authored-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Adds a cache mapping goroutine IDs to goroutine objects, this allows
speeding up FindGoroutine and makes commands like 'goroutines -t' not
be accidentally quadratic in the number of goroutines.
Specifically, make sure that both DebugActiveProcess and
WaitForDebugEvent Windows APIs are executed on the same thread.
Otherwise WaitForDebugEvent fails with ERROR_INVALID_HANDLE as per its
documentation
https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-waitfordebugevent
'... Only the thread that created the process being debugged can call
WaitForDebugEvent. ...'
Fixes#1825
Due to a bug in the Go compiler midstack inlined calls do not report
their ranges correctly. We can't check if an address is in the range of
a DIE by simply looking at that DIE's range, we should also recursively
check the DIE's children's ranges.
Also fixes the way stacktraces of midstack inlined calls are reported
(they used to be inverted, with the deepest inlined stack frame
reported last).
Fixes#1795
Adds an API call that returns a list of packages contained in the
program and the files that were used to build them, and also a best
guess at which filesystem directory contained the package when it was
built.
This can be used by IDEs to map file paths if the debugging environment
doesn't match the build environment exactly.
When attaching to a process in linux ElfUpdateSharedObjects will be
called for the first time during the call to updateThreadList,
unfortunately it won't do anything because the dynamic section of the
base elf executable needs to have been read first and that's done when
we initialize the BinaryInfo object (which happens later during the
call to initialize).
Remove build tags from disassembler code, move architecture specific
functionality inside proc.Arch.
This is necessary because Delve should be able to debug corefiles
cross-platform.
* fix TestKill test:
It will fail in Open /proc/pid/ sporadicly since there is no any sync between signal sended(tracee handled) and open /proc/%d/, especially in some weak arm64 cpu. Skip /proc check on arm64.
* remove skip-code of Detach tests.
arm64 use hardware breakpoint, and it will not set PC to the next instruction like amd64. Let adjustPC always fasle in arm64, in case of infinite loop.
PtraceSingleStep cannot step over BRK instruction(linux-arm64 feature or kernel bug maybe).
GDB has the same question too, it will hang on forever with c command or execute that instruction indefinitely with s,si command.
SetPC+BreakpointSize to jump over BRK to prevent repeating the instruction indefinitely.
Co-authored-by: tykcd996 <tang.yuke@zte.com.cn>
Co-authored-by: hengwu0 <wu.heng@zte.com.cn>
* delve now can be built to arm64-arch and running on linux-arm64 OS.
* arm64 general-purpose registers have completed.
* arm64 disasm has completed.
Co-authored-by: tykcd996 <tang.yuke@zte.com.cn>
Co-authored-by: hengwu0 <wu.heng@zte.com.cn>
As proc/native is arch related, it should move some functions to arch-relate file. And this patch can help us to separate the architecture code, make code tidy. So that the merge of arm64 code later will not cause chaos.(#118)
Use the name specified by compile unit attribute DW_AT_go_package_name,
introduced in Go 1.13, to map package names to package paths, instead of
trying to deduce it from names of types.
Also use this mapping for resolving global variables and function
expressions.
* Makefile: discard stderr of "go list"
In module mode "go" will print messages about downloading modules to
stderr, we shouldn't confuse them for the real command output.
* proc/core: enable PIE tests
PIE tests for core files were never enabled due to a missing flag.Parse
call.
* proc/linux: do not route signals to threads while stopping
While we are trying to stop the process we should not route signals
sent to threads because that will result in threads being resumed.
Also keep better track of which threads are stopped.
This fixes an incompatibility with Go 1.14, which sends a lot of
signals to its threads to implement non-cooperative preemption,
resulting in Delve hanging waiting for an already-stopped thread to
stop.
In principle however this bug has nothing to do with Go 1.14 and could
manifest in any instance of high signal pressure.
* Makefile: discard stderr of "go list"
In module mode "go" will print messages about downloading modules to
stderr, we shouldn't confuse them for the real command output.
Instead of just sending unhandled signals back to the process send them
to the specific thread that received them.
This is important because:
1. debugserver does not appear to support the vCont;CXX packet without
specifying a target thread
2. the non-cooperative preemption change in an upcoming version of Go
(1.15?) will require sending signals to a specific thread.
Fixes#1744
Modifies FindFileLocation, FindFunctionLocation and LineToPC as well as
service/debugger to support inlining and introduces the concept of
logical breakpoints.
For inlined functions FindFileLocation, FindFunctionLocation and
LineToPC will now return one PC address for each inlining and one PC
for the concrete implementation of the function (if present).
A proc.Breakpoint will continue to represent a physical breakpoint, at
a single memory location.
Breakpoints returned by service/debugger, however, will represent
logical breakpoints and may be associated with multiple memory
locations and, therefore, multiple proc.Breakpoints.
The necessary logic is introduced in service/debugger so that a change
to a logical breakpoint will be mirrored to all its physical
breakpoints and physical breakpoints are aggregated into a single
logical breakpoint when returned.
program
When evaluating type casts always resolve array types.
Instead of resolving them by looking up the string in debug_info
construct a fake array type so that a type cast to an array type always
works as long as the element type exists.
We already did this for byte arrays, this commit extends this to any
array type. The reason is that we return a fake array type (that
doesn't exist in the target program) for the array of a channel type.
Fixes#1736
Fixes a case of breakpoint confusion on resume caused by having two
breakpoints one byte apart. This bug can cause the target program to
resume execution a single byte inside an instruction and crash either
with SIGILL or a SIGSEGV, or misbehave (depending on how the truncated
instruction is decoded).
native.(*Thread).StepInstruction should call FindBreakpoint using
adjustPC==false because at that point the PC of the thread should
already have been adjusted (and it has been).
Make the 'list' command succeed for file:line expressions that don't
map to any instruction.
Adds an argument to the FindLocations API call that makes FindLocations
return if the expression can be parsed, even if it doesn't end up
matching any instruction in debug_line.
Adds a '-r' option to the 'restart' command (and to the Restart API)
that re-records the target when using rr.
Also moves the code to delete the trace directory inside the gdbserial
package.
Splits the code that loads function information from debug_info into
multiple functions.
This makes the changes needed to implement logical breakpoints easier
to make.
Trust argument order to determine argument frame layout when calling
functions, this allows calling optimized functions and removes the
special cases for runtime.mallocgc.
Fixes#1589
Add options to start a stacktrace from the values saved in the
runtime.g struct as well as a way to disable the stackSwitch logic and
just get a normal stacktrace.
If a closure captures a variable but also defines a variable of the
same name in its root scope the shadowed flag would, sometimes, not be
appropriately applied to the captured variable.
This change:
1. sorts the variable list by depth *and* declaration line, so that
closure captured variables always appear before other root-scope
variables, regardless of the order used by the compiler
2. marks variable with the same name as shadowed even if there is only
one scope at play.
This fixes the problem but as a side effect:
1. programs compiled with Go prior to version 1.9 will have the
shadowed flag applied arbitrarily (previously the shadowed flag was not
applied at all)
2. programs compiled with Go prior to versoin 1.11 will still exhibit
the bug, as they do not have DeclLine information.
Fixes#1672
The fix for #1428 was buggy, partly because I communicated poorly. Sorry
about that.
The size of the TLS segment should be padded such that TLS addresses
are congruent in the file to where they will end up memory, i.e.
(tlsoffset%align) == (vaddr%align). In most cases, vaddr will be aligned
and it won't matter, but if not then simply aligning the end of the
segment is incorrect. This should be right.
(For the record, the current rounding logic is working in bits, but
PtrSize is in bytes, so it wasn't working as originally intended
either.)
Intent here is to bring optargorder up to date with delve
and keep it in sync (and to use optargorder to help monitor
compiler output for debugging quality regressions).
proc.Next and proc.Step will call, after setting their temp
breakpoints, curthread.SetCurrentBreakpoint. This is intended to find
if one of the newly created breakpoints happens to be at the same
instruction that curthread is stopped at.
However SetCurrentBreakpoint is intended to be called after a Continue
and StepInstruction operation so it will also detect if curthread is
stopped one byte after a breakpoint.
If the instruction immediately preceeding the current instruction of
curthread happens to:
1. have one of the newly created temp breakpoints
2. be one byte long
SetCurrentBreakpoint will believe that we just hit that breakpoint and
therefore the instruction should be repeated, and thus rewind the PC of
curthread by 1.
We should distinguish between the two uses of SetCurrentBreakpoint and
disable the check for "just hit" breakpoints when inappropriate.
Fixes#1656
Moves EvalScope methods to the proper file and organizes everything
together. Also makes some EvalScope methods no longer methods and just
pure functions.
* proc: fix stacktraces when a SIGSEGV happens during a cgo call
When a SIGSEGV happens in a cgo call (for example as a result of
dereferencing a NULL pointer) the stack layout will look like this:
(system stack) runtime.fatalthrow
(system stack) runtime.throw
(system stack) runtime.sigpanic
(system stack) offending C function
... other C functions...
(system stack) runtime.asmcgocall
(goroutine stack) call inside cgo
The code in switchStack would switch directly from the
runtime.fatalthrow frame to the first frame in the goroutine stack,
hiding important information.
Disable this switch for runtime.fatalthrow and reintroduce the check
for runtime.mstart that existed before this version of the code was
implemented in commit 7bec20.
This problem was reported in comment:
https://github.com/go-delve/delve/issues/935#issuecomment-512182533
* cmd/dlv: actually disable C compiler optimizations when building
* *: Add .cirrus.yml for FreeBSD testing
* *: run go mod tidy
* service/test: prefer 127.0.0.1 over localhost
* dwarf/line: fix TestDebugLinePrologueParser
* vendor: rerun go mod vendor
Propagate signals when stepping because debugserver will report them,
from the issue:
2019-07-11T16:31:25+02:00 debug layer=gdbconn <- $z0,105525d,1#c9
2019-07-11T16:31:25+02:00 debug layer=gdbconn -> $OK#00
2019-07-11T16:31:25+02:00 debug layer=gdbconn <- $vCont;s:c41c3#50
2019-07-11T16:31:25+02:00 debug layer=gdbconn -> $T1cthread:c41c3;threads:c41c3,c41d7,c41d8,c41d9,c41da;thread-pcs:105525d,7fffc464bf46,7fffc464bbf2,7fffc464bbf2,7fffc46...
2019-07-11T16:31:25+02:00 debug layer=gdbconn <- $Z0,105525d,1#a9
2019-07-11T16:31:25+02:00 debug layer=gdbconn -> $OK#00
in this case we request a single step on thread c41c3 but debugserver
reports instead a signal (in this case SIGWINCH).
Fixes#1610
Add variables flag to mark variables that are allocated on a register
(and have no address) and variables that we read as result of a
function call (and are allocated on a stack that no longer exists when
we show them to the user).
Increases the maximum string length from 64 to 1MB when loading strings
for a binary operator, also delays the loading until it's necessary.
This ensures that comparison between strings will always succeed in
reasonable situations.
Fixes#1615
Backports debug/dwarf commit: 535741a69a1300d1fe2800778b99c8a1b75d7fdd
CL: https://go-review.googlesource.com/18459
The x/debug/dwarf that we used for dwarf/godwarf/type.go was forked
from debug/dwarf long before this commit.
Original description:
Currently readType simultaneously constructs a type graph and resolves
the sizes of the types. However, these two operations are
fundamentally at odds: the order we parse a cyclic structure in may be
different than the order we need to resolve type sizes in. As a
result, it's possible that when readType attempts to resolve the size
of a typedef, it may dereference a nil Type field of another typedef
retrieved from the type cache that's only partially constructed.
To fix this, we delay resolving typedef sizes until the end of the
readType recursion, when the full type graph is constructed.
Fixes#1601
* proc: allow simultaneous call injection to multiple goroutines
Changes the call injection code so that we can have multiple call
injections going on at the same time as long as they happen on distinct
goroutines.
* proc: fix EvalExpressionWithCalls for constant expressions
The lack of address of constant expressions would confuse EvalExpressionWithCalls
Fixes#1577
* tests: fix tests for Go 1.13
- Go 1.13 doesn't autogenerate init functions anymore, tests that
expected that now fail and should be skipped.
- Plugin tests now need -gcflags'all=-N -l' now, we were probably
getting lucky with -gcflags='-N -l' before.
* proc: allow signed integers as shift counts
Go1.13 allows signed integers to be used as the right hand side of a
shift operator, change eval to match.
* goversion: update maximum supported version
* travis: force Go to use vendor directory
Travis scripts get confused by "go: downloading" lines, the exact
reason is not clear. Testing that the vendor directory is up to date is
a good idea anyway.
Support for bulk queries makes the DWARF quality checker
(github.com/dr2chase/dwarf-goodness/cmd/dwarf-goodness)
run much more efficiently (replace quadratic cost with
linear).
The location specified '<fnname>:0' could be used to set a breakpoint
on the entry point of the function (as opposed to locspec '<fnname>'
which sets it after the prologue).
Setting a breakpoint on an entry point is almost never useful, the way
this feature was implemented could cause it to be used accidentally and
there are other ways to accomplish the same task (by setting a
breakpoint on the PC address directly).
Also fixes findCompileUnitForOffset which was broken in some edge cases
(when looking up an offset inside the last child of the compilation
unit) which don't happen in normal executables (we only look up types, and those
are always direct childs of compile units).
Allow changing the value of a string variable to a new literal string,
which requires calling runtime.mallocgc to allocate the string into the
target process.
This means that a command like:
call f("some string")
is now supported.
Additionally the command:
call s = "some string"
is also supported.
Fixes#826
The bitmasks for transforming a 64-bit register into it's lower-bit
counterparts (e.g. RAX -> EAX -> AX -> AH/AL) were incorrect. This patch
fixes the bitmasks and adds an additional test.
Childless compile units would confuse loadDebugInfoMaps.
No test because I don't know what causes go to invoke GNU As in such a
way that it produces a childless compile unit.
Fixes#1572
Instead of reading partial units as we see them skip them entirely and
then re-read them when they are imported, directly into the destination
compile unit.
This avoids a lot of duplicate code in the loadDebugInfoMaps function
and will simplify implementing logical breakpoints and support for the
new DW_AT_go_package_name attribute added in Go 1.13.
The current wording is confusing - the file exists and the line exists, so what is the problem? I suspect this ambiguity is behind #1496 and likely others.
Also I updated the style to return values like the rest of the code in the file, which is also more readable (IMO and per https://github.com/golang/go/wiki/CodeReviewComments#named-result-parameters)
* proc: support nested function calls
Changes the code in fncall.go to support nested function calls.
This changes delays argument evaluation until after we have used
the call injection protocol to allocate an argument frame. When
evaluating the parse tree of an expression we'll initiate each
function call we find on the way down and then complete the function
call on the way up.
For example. in:
f(g(x))
we will:
1. initiate the call injection protocol for f(...)
2. progress it until the point where we have space for the arguments
of 'f' (i.e. when we receive the debugCallAXCompleteCall message
from the target runtime)
3. inititate the call injection protocol for g(...)
4. progress it until the point where we have space for the arguments
of 'g'
5. copy the value of x into the argument frame of 'g'
6. finish the call to g(...)
7. copy the return value of g(x) into the argument frame of 'f'
8. finish the call to f(...)
Updates #119
* proc: bugfix: closure addr was wrong for non-closure functions
The initial implementation of the 'call' command required the
function call to be the root expression, i.e. something like:
double(3) + 1
was not allowed, because the root expression was the binary operator
'+', not the function call.
With this change expressions like the one above and others are
allowed.
This is the first step necessary to implement nested function calls
(where the result of a function call is used as argument to another
function call).
This is implemented by replacing proc.CallFunction with
proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run
proc.(*EvalScope).EvalExpression in a different goroutine. This
goroutine, the 'eval' goroutine, will communicate with the main
goroutine of the debugger by means of two channels: continueRequest
and continueCompleted.
The eval goroutine evaluates the expression recursively, when
a function call is encountered it takes care of setting up the
function call on the target program and writes a request to the
continueRequest channel, this causes the 'main' goroutine to restart
the target program by calling proc.Continue.
Whenever Continue encounters a breakpoint that belongs to the
function call injection protocol (runtime.debugCallV1 and associated
functions) it writes to continueCompleted which resumes the 'eval'
goroutine.
The 'eval' goroutine takes care of implementing the function call
injection protocol.
When the expression is fully evaluated the 'eval' goroutine will
write a special message to 'continueRequest' signaling that the
expression evaluation is terminated which will cause Continue to
return to the user.
Updates #119
This change splits the BinaryInfo object into a slice of Image objects
containing information about the base executable and each loaded shared
library (note: go plugins are shared libraries).
Delve backens are supposed to call BinaryInfo.AddImage whenever they
detect that a new shared library has been loaded.
Member fields of BinaryInfo that are used to speed up access to dwarf
(Functions, packageVars, consts, etc...) remain part of BinaryInfo and
are updated to reference the correct image object. This simplifies this
change.
This approach has a few shortcomings:
1. Multiple shared libraries can define functions or globals with the
same name and we have no way to disambiguate between them.
2. We don't have a way to handle library unloading.
Both of those affect C shared libraries much more than they affect go
plugins. Go plugins can't be unloaded at all and a lot of name
collisions are prevented by import paths.
There's only one problem that is concerning: if two plugins both import
the same package they will end up with multiple definition for the same
function.
For example if two plugins use fmt.Printf the final in-memory image
(and therefore our BinaryInfo object) will end up with two copies of
fmt.Printf at different memory addresses. If a user types
break fmt.Printf
a breakpoint should be created at *both* locations.
Allowing this is a relatively complex change that should be done in a
different PR than this.
For this reason I consider this approach an acceptable and sustainable
stopgap.
Updates #865
Remove the breakpoint set in TestCallConcurrent so that it doesn't
interfere with the call injection protocol.
The fact that it can is a bug but that bug is better addressed after
PRs #1503 and #1504 are merged, this keeps tests happy in the meantime.
Fixes#1542
Go 1.12 introduced a change to the internal map representation where
empty map cells can be marked with a tophash value of 1 instead of just
0.
Fixes#1531
RestoreRegisters on linux would also restore FS_BASE and GS_BASE, if
the target goroutine migrated to a different thread during the call
injection this would result in two threads of the target process
pointing to the same TLS area which would greatly confuse the target
runtime, leading to fatal panics with nonsensical stack traces.
Other backends are unaffected:
- native/windows doesn't store the TLS in the same CONTEXT struct as
the other register values.
- native/darwin doesn't support function calls (and wouldn't store the
TLS value in the same struct)
- gdbserial/rr doesn't support function calls (because it's a
recording)
- gsdbserial/lldb extracts the value of TLS by executing code in the
target process.
* *: use loglevel to control what gets logged instead of output redirection
This stops logrus from doing all the formatting just to discard it
immediately afterwards.
* logflags: replace default formatter of logrus
The default formatter of logrus emits logs in two different formats
depending on whether or not the output is going to a terminal. The
output format for non-terminals is indented to be machine readable, but
we mostly read logs ourselves and the excessive quoting makes that
format unreadable.
When outputting to terminals it uses ANSI escape codes unconditionally,
without checking whether the terminal it is connected to actually
supports colors.
This commit replaces the default formatter with a much simpler
formatter that always uses a more readable format, doesn't use colors
and places the key-value pairs at the beginning of the line (which is a
better match for how we use them).
* cmd/dlv: add command line options to redirect logs
Adds two options, --log-to-file and --log-to-fd, to redirect logs to a
file or to a file descriptor.
When one of those two options is specified the "API server listening
at:" message will also be redirected to the specified file/file
descriptor.
This allows clients that want to use the "API server listening at:"
message to do so even if they want to redirect the target's stdout to
another file or device.
Implements #1179, #1523
Adds initial support for plugins, this is only the code needed to keep
track of loaded plugins on linux (both native and gdbserial backend).
It does not actually implement support for debugging plugins on linux.
Updates #865
Like we do with unrecovered panics, create a default breakpoint to
catch runtime errors that will cause the program to terminate.
Primarily intended to give users the opportunity to examine the state
of a deadlocked process.
runtime.clone (on some operating systems?) work similarly to fork:
when a thread calls runtime.clone a new thread is created. For a
short period of time both the parent thread and the child thread
appear to be running the same goroutine, until the child thread
adjusts its TLS to point to the correct goroutine.
This means that proc.GetG for a thread that's currently running
'runtime.clone' could be wrong and, consequently, the field
proc.(G).thread of a G struct returned by GoroutinesInfo could be
also wrong. And, finally, that FindGoroutine could sometimes return
a *G with a bad associated thread if the goroutine of interest
recently called 'runtime.clone'.
To work around this problem this commit makes two changes:
1. proc.GetG will return nil for all threads executing runtime.clone.
2. FindGoroutine will return the selected goroutine as long as the
ID matches the one requested.
Change (1) takes care of the 'runtime.clone' problem. If we stop
the target process shortly after a thread executed the SYSCALL
instruction in 'runtime.clone' there are three possibilities:
a. Both the parent thread and the child thread are stopped inside
'runtime.clone'. In this case the state we report is slightly
incorrect, because both threads will be reported as not running any
goroutine when we do know which goorutine one of them (the parent)
is running. This doesn't actually matter since runtime.clone is
always called on the system stack and therefore the goroutine in
runtime.allgs will have the correct location.
b. The child thread managed to exit 'runtime.clone' but the parent
thread didn't. This is similar to (a) but in this case GetG on the
child thread will return the correct goroutine. GetG on the parent
thread will still return (incorrectly) nil but this doesn't matter
for the samer reason as described in (a).
c. The parent thread managed to exit 'runtime.clone' but the child
thread didn't. In this case GetG will return the correct goroutine
both for the parent thread (because it's not executing runtime.clone)
and the child thread.
Change (2) means that even if a thread has a completely nonsensical
TLS (for example because it's set through cgo) evaluating a variable
with a valid GoroutineID will still work as long as it's the current
goroutine (which is the most common case). This change also doubles
as an optimization for FindGoroutine.
Fixes#1469
