- 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
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.
* logflags,proc: flag to log stacktrace execution
Add a log flag to write logs about what the stacktracer does.
* proc: read context from sigtrampgo, fixes TestCgoStacktrace2 on 1.21
Changes stacktrace code to read the signal context from the arguments
of sigtrampgo.
Also changes the automatic fatalthrow breakpoint for go 1.21.
In combination these two changes fix TestCgoStacktrace2 on Go 1.21 on
various platforms.
Only print the warning that gopclntab can not be read for the first
image (i.e. the executable file), also change the returned when neither
DWARF nor gopclntab are found to preserve the DWARF error.
We used to parse the .gopclntab section but removed support in favor of
simply using DWARF debug information, due to lack of C symbols among
other reasons. This makes it impossible to debug stripped binaries,
which some distrubutions ship by default.
Add back in basic support for .gopclntab which survives if the binary
is stripped, allowing for rudimentary debugging such as basic
program navigation, tracing, etc...
Go 1.21 renamed runtime._type to internal/abi.Type and changed the name
of its fields. Update Delve so that it uses the new names for loading
interfaces and generic type parameters.
Read the command line of the main target process as well as any other
process Delve attaches to in follow exec mode.
The command line can be viewed using the 'target list' command.
In follow exec mode this command line is used to match the follow exec
regex to decide whether or not to attach to a child process.
On macOS or when using rr the list of arguments is not available for
attached processes since there is no way to use the gdb serial protocol
to read it.
Fixes#2242
When using Step on a function that has a dynamic CALL instruction we
set a Step breakpoint on the call.
When it is hit we determine the destination of the CALL by looking at
registers, set a breakpoint there and continue.
If the Step breakpoint is hit simultaneously with a normal breakpoint
our Step logic will take precedence and the normal breakpoint hit will
be hidden from the user.
Move the Step logic to a breaklet callback so that it does not
interfere with the decision to stop.
deref'd
Fix infinite recursion if escapeCheck, at some point during its
recursion, creates an unreadable variable.
The deeper reason for this is that we evaluate function calls in a very
weird order so that we can always have stack space to store
intermediate evaluation results.
The variable 'value' happens to be stored in a register when we try to
make the call and because of our weird evaluation strategy registers
are no longer available to us when we evaluate 'value'.
This is not a complete fix for the issue, the real fix would be to
evaluate everything in its natural order, storing intermediate values
in Delve's memory instead of the target's stack. To do this we need a
mechanism to pin heap allocated objects, which at the moment does not
exist.
Updates #3310
The compiler produces ABI compatibility wrappers for some functions.
We have changed the support for breakpoints to allow a single logical
breakpoint to correspond to multiple physical breakpoints, take
advantage of that to set breakpoints on both the ABI wrapper and the
real function.
Fixes#3296
Adds the ability to automatically debug child processes executed by the
target to the linux native backend.
This commit does not contain user interface or API to access this
functionality.
Updates #2551
Delve no longer compiles on Go1.12 and earlier, we don't test it on
these versions and they are 4 years old and unsupported. Remove some
code related to Go 1.12 and earlier, mostly from tests.
- use PT_SUSPEND/PT_RESUME to control running threads in
resume/stop/singleStep
- change manual stop signal from SIGTRAP to SIGSTOP to make manual stop
handling simpler
- change (*nativeProcess).trapWaitInternal to suspend newly created
threads when we are stepping a thread
- change (*nativeProcess).trapWaitInternal to handle some unhandled
stop events
- remove misleading (*nativeProcess).waitFast which does not do
anything different from the normal wait variant
- rewrite (*nativeProcess).stop to only set breakpoints for threads of
which we have received SIGTRAP
- rewrite (*nativeThread).singleStep to actually execute a single
instruction and to properly route signals
* Test windows/arm64 pipeline
* update build script to support windows/arm64
* skip TestLaunchRequestWithRelativeExecPath is symblink can't be created
* partially fix and skip TestCgoStacktrace
* update backend health docs
* update
* log test output
* skip starbind test on windows arm64
* skip starbind test on windows arm64
* skip rtype test on windows arm64
* skip pie backend tests on windows/arm64
* fix tests
* skip function calls test on windows/arm64
* fix tests
* revert hardware breakpoint test relax
* add pie test clarification
* skip symlink test only on windows
* skip TestStepConcurrentDirect
* readd exp.winarm64
* fix param
* add exp.winarm64 tags
* skip TestGeneratedDoc on winarm64
Go change 064f34f (which exists in Go 1.19.2 and following) removed the
pagezero_size option from linker calls (because it is deprecated). This
expanded the problem that exists on darwin/arm64 as well as PIE builds
on darwin/amd64 to all darwin/amd64 builds.
This problem is described on: https://github.com/golang/go/issues/25841.
This commit extends the darwin/arm64 workaround to darwin/amd64.
Fixes#3194
- updated go/packages to support new export format
- rewrite testinline.go fixture because the compiler got too smart with
constant folding
- temporarily disable staticcheck on go1.20 because it doesn't support
the new export format.
- workaround for go.dev/cl/429601
This patch introduces some changes, particularly to arm64SwitchStack
which fixes the test when running on linux/arm64. The changes causes the
same test to fail on darwin/m1 so temporarily keeping both versions.
Next step should be to refactor and unify the two so they both work with
the same function.
Fixes#2340
* Add support for windows/arm64
* split sentinel files and add winarm64 experiment
* update loadBinaryInfoPE to support PIE binaries
* skip TestDump on windows/arm64
* run windows/arm64 compilation on windows/amd64
* add entry point check for pie binaries
* delete unusded code
* document windows/arm64 breakpoint
* implement changing windows/arm64 fp registers
* update crosscall offset names
* fix G load when using CGO
* fix testvariablescgo
* remove DerefGStructOffset
* derefrence gstructoffset in GStructOffset() if necessary
Go 1.20 switched to uint64 to represent goroutine IDs, we can't
actually follow suit because we have allowed clients to use -1 to refer
to the currently selected goroutine, however we should at least switch
to int64 and also update the rtype check to accept the 1.20 type.
As we parse this informatin in the loop we must take care to assemble
things correctly. In this situation when we encounter a file name,
the dir index is -1, then subsequently we get the correct dir index
for that file and can put them together. Previously we were adding the
file and then the directory location to the file list instead of
correctly concatenating them, resulting in an incorrect file list making
indexing into the list return incorrect results later on.
Introduces a new TargetGroup abstraction that can be used to manage
multiple related targets.
No actual management of child processes is implemented here, this is
just a refactoring to make it possible to do that in the future.
Updates #2551
Adds a LogicalBreakpoint type to represent logical breakpoints
explicitly. Until now logical breakpoints were constructed implicitly
by grouping physical breakpoints together by their LogicalID.
Having logical breakpoints represented explicitly allows for a simpler
implementation of disabled breakpoints, as well as allowing a simple
implementation of delayed breakpoints (#1653, #2551) and in general of
breakpoints spanning multiple processes if we implement debugging
process trees (#2551).
Updates #1653
Updates #2551
debugCallV2 for amd64 has a bug where it corrupts the flags registers
every time it is called, this commit works around that problem by
restoring flags one extra time to its original value after stepping out
of debugCallV2.
Fixes#2985
Moves breakpoindIDCounter out of BreakpointsMap and into
service/debugger.Debuggger to simplify proc.Target's API and aid with
implementing fork follow mode, where we'll have to debug multiple
processes simultaneously.
This commit improves the handling of hardcoded breakpoints in Delve.
A hardcoded breakpoint is a breakpoint instruction hardcoded in the
text of the program, for example through runtime.Breakpoint.
1. hardcoded breakpoints are now indicated by setting the breakpoint
field on any thread stopped by a hardcoded breakpoint
2. if multiple hardcoded breakpoints are hit during a single stop all
will be notified to the user.
3. a debugger breakpoint with an unmet condition can't hide a hardcoded
breakpoint anymore.
It's possible that an inlined function call also contains an inlined
sunroutine. In this case we should also parse the children of
inlined calls to ensure we don't lose this information.
* service/debugger: disable breakpoints with hitcond not satisfiable
To avoid slowing down the debugged process unnecessarily, we disable
breakpoints with a hit condition that can no longer be hit again.
* test: add integration tests for hit conditions no more satisfiable
* proc/test: fix typo in breakpoints related tests
* test: use the new API for hitcond integration tests
* go.mod: update golang.org/x/tools to v0.1.8
Fixes TestGeneratedDoc on go1.18
* TeamCity: bump test matrix
Add 1.18 to test matrix. Remove 1.15 from test matrix and from support range.
* proc,tests: update for regabi on arm64 and 386
Make sure that stacktrace registers always contain the PC register of
the current frame, even though the debug_frame rules might not specify
it on architectures that use a link register.
The PC register is needed to look up loclist entries for variable
evaluation.
* goversion: bump maximum supported Go version to 1.18
* proc: disable asyncpreempt on linux/arm64
Asyncpreempt on linux/arm64 can sometimes restart a sequence of
instructions which will make breakpoint appear to be hit twice in some
cases.
Fix signal handling during thread single stepping so that signals that
are generated by executing the current instruction are immediately
propagated to the inferior, while signals other signals sent to the
thread are delayed until the full resume happens.
Fixes a bug where a breakpoint set on an instruction that causes a
SIGSEGV would make Delve hang and a bug where signals received during
single step would make it look like an instruction is executed twice.
Fixes#2801Fixes#2792
* made Pid a method of Target instead of a method of Process
* changed argument of NewTarget to ProcessInternal, since that's the
interface that backends have to implement
* removed warnings about ProcessInternal since there is no way for
users of pkg/proc to access those methods anyway
* made RecordingManipulation an optional interface for backends, Target
supplies its own dummy implementation when the backend doesn't
* inlined small interfaces that only existed to be inlined in
proc.Process anyway
* removed unused function findExecutable in the Windows and no-native
darwin backends
* removed (*EvalScope).EvalVariable, an old synonym for EvalExpression
Debugserver has a bug where writing to a AVX-2 or AVX-512 register does
not work unless it is followed by at least a write to a AVX (not 2 or
512) register.
See also: https://bugs.llvm.org/show_bug.cgi?id=52362Fixes#2767
There are persistent issues with watchpoints on Windows, it is not
clear whether it's a problem with the VM running the tests or if there
is a real bug in our implementation of hardware breakpoints on Windows.
Until the cause can be determined watchpoints on Windows will be
disabled.
Updates #2768
* service/dap: remove deadlock in TestLaunchDebugRequest
Fixes#2746
* terminal: fix TestScopePrefix flakiness
When there are more than 10 frames api.PrintStack will prefix the
output with spaces to right justify the frame number, which confuses
TestScopePrefix.
* _scripts: pass -buildvcs for Go 1.18 and later on TeamCity
Go 1.18 will try to stamp builds with the VCS version, this doesn't
work on TeamCity because the checkout isn't a valid repository (but
looks like it).
Pass -buildvcs=false to disable this feature.
* proc: switch to goroutine stack if first frame's func can not be found
If the first frame on the system stack can not be resolved to a
function switch directly to the goroutine stack.
* proc/native: always stop after RequestManualStop on Windows
On Windows RequestManualStop will generate an exception on a special
DbgUiRemoteBreakin thread, sometimes this thread will die before we
finish stopping the process. We need to account for that and still stop
even if the thread is gone and no other thread hit a breakpoint.
Fixes flakiness of TestIssue419.
* proc/native: fix watchpoints with new threads on Windows
When a new thread is created we must reapply all watchpoints to it,
like we do on linux.
* tests: be lenient on goroutinestackprog tests on Windows
We can not guarantee that we find all goroutines stopped in a good
place and sometimes the stacktrace fails on Windows.
Adds watchpoint support to gdbserver backend for rr debugger and
debugserver on macOS/amd64 and macOS/arm64.
Also changes stack watchpoints to support reverse execution.
With generics a single function can have multiple concrete
instantiations, the old version of FindFileLocation supported at most
one concrete instantiation per function and any number of inlined
calls, this supports any number of inlined calls and concrete
functions.
When the function we are calling is an autogenerated stub (because, for
example, we are calling it through a function pointer) the declaration
line of variables is meaningless and could cause us to discard valid
return arguments.
Go 1.18 removed the jmpdefer call from deferreturn, now deferreturn is
a normal function call that can appear on the stack, rules for
detecting a deferreturn call must be changed and new code must be added
to skip it while stepping out.
Internal breakpoints do not need IDs and assigning them from a counter
separate from the user ID counter can be a cause of confusion.
If a user breakpoint is overlayed on top of a pre-existing internal
breakpoint the temporary ID will be surfaced as if it was a user ID,
possibly conflicting with another user ID.
If a temporary breakpoint is overlayed on top of a pre-existing user
breakpoint and the user breakpoint is first deleted and then
re-created, the user ID will be resurrected along with the breakpoint,
instead of allocating a fresh one.
This change removes internal breakpoint IDs entirely, only user
breakpoints receive an ID.
In order for DAP to support halting the program (either manually or on a breakpoint) performing some action and then resuming execution, there needs to be a way to stop the program without clearing the internal breakpoints. This is necessary for log points and stopping the program to set breakpoints.
The debugging UI makes it seem like a user should be able to set or clear a breakpoint at any time. Adding this ability to complete synchronous requests while the program is running is thus important to create a seamless user experience.
This change just adds a configuration to determine whether the target should clear the stepping breakpoints, and changes the server to use this new mode. Using the new mode means that the DAP server must determine when it expect the next to be canceled and do this manually.
* terminal,service: add way to see internal breakpoints
Now that Delve has internal breakpoints that survive for long periods
of time it will be useful to have an option to display them.
* proc,terminal,service: support stack watchpoints
Adds support for watchpoints on stack allocated variables.
When a stack variable is watched, in addition to the normal watchpoint
some support breakpoints are created:
- one breakpoint inside runtime.copystack, used to adjust the address
of the watchpoint when the stack is resized
- one or more breakpoints used to detect when the stack variable goes
out of scope, those are similar to the breakpoints set by StepOut.
Implements #279
* proc: move breakpoint condition evaluation out of backends
Moves breakpoint condition evaluation from the point where breakpoints
are set, inside ContinueOnce, to (*Target).Continue.
This accomplishes three things:
1. the breakpoint evaluation method needs not be exported anymore
2. breakpoint condition evaluation can be done with a full scope,
containing a Target object, something that wasn't possible before
because ContinueOnce doesn't have access to the Target object.
3. moves breakpoint condition evaluation out of the critical section
where some of the threads of the target process might be still
running.
* proc/native: handle process death during stop() on Windows
It is possible that the thread dies while we are inside the stop()
function. This results in an Access is denied error being returned by
SuspendThread being called on threads that no longer exist.
Delay the reporting the error from SuspendThread until the end of
stop() and only report it if the thread still exists at that point.
Fixes flakyness with TestIssue1101 that was exacerbated by moving
breakpoint condition evaluation outside of the backends.
* pkg/proc: Prefer throw instead of fatalthrow
Currently there is a breakpoint set at runtime.fatalthrow to catch any
situation where the runtime crashes (e.g. deadlock).
When we do this, we go up a frame in order to parse the crash reason.
The problem is that there is no guarentee the "s" variable we attempt to
parse will still be considered "live".
Since runtime.fatalthrow is never called directly, set a breakpoint on
runtime.throw instead and prevent having
to search up a stack frame in order to
get the throw reason.
Fixes#2602
* service/dap: Fix TestFatalThrowBreakpoint
* Reenable TestFatalThrow DAP test
* service/dap: Don't skip test on < 1.17
* service/dap: Update test constraint for 1.16
* pkg/proc: Reinstate runtime.fatalthrow as switchstack exception
Changes Breakpoint to allow multiple overlapping internal breakpoints
on the same instruction address.
This is done by changing the Breakpoint structure to contain a list of
"breaklets", each breaklet has a BreakpointKind and a condition
expression, independent of the other.
A breakpoint is considered active if any of its breaklets are active.
A breakpoint is removed when all its breaklets are removed.
We also change the terminology "internal breakpoint" to "stepping
breakpoint":
HasInternalBreakpoints -> HasSteppingBreakpoints
IsInternal -> IsStepping
etc...
The motivation for this change is implementing watchpoints on stack
variables.
Watching a stack variable requires also setting a special breakpoint to
find out when the variable goes out of scope. These breakpoints can not
be UserBreakpoints because only one user breakpoint is allowed on the
same instruction and they can not be internal breakpoints because they
should not be cleared when a next operation is completed (they should
be cleared when the variable watch is cleared).
Updates #279
* proc: support new Go 1.17 panic/defer mechanism
Go 1.17 will create wrappers for deferred calls that take arguments.
Change defer reading code so that wrappers are automatically unwrapped.
Also the deferred function is called directly by runtime.gopanic, without going through runtime.callN which means that sometimes when a panic happens the stack is either:
0. deferred function call
1. deferred call wrapper
2. runtime.gopanic
or:
0. deferred function call
1. runtime.gopanic
instead of always being:
0. deferred function call
1. runtime.callN
2. runtime.gopanic
the isPanicCall check is changed accordingly.
* test: miscellaneous minor test fixes for Go 1.17
* proc: resolve inlined calls when stepping out of runtime.breakpoint
Calls to runtime.Breakpoint are inlined in Go 1.17 when inlining is
enabled, resolve inlined calls in stepInstructionOut.
* proc: add support for debugCallV2 with regabi
This change adds support for the new debug call protocol which had to
change for the new register ABI introduced in Go 1.17.
Summary of changes:
- Abstracts over the debug call version depending on the Go version
found in the binary.
- Uses R12 instead of RAX as the debug protocol register when the binary
is from Go 1.17 or later.
- Creates a variable directly from the DWARF entry for function
arguments to support passing arguments however the ABI expects.
- Computes a very conservative stack frame size for the call when
injecting a call into a Go process whose version is >=1.17.
Co-authored-by: Michael Anthony Knyszek <mknyszek@google.com>
Co-authored-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
* TeamCity: enable tests on go-tip
* goversion: version compatibility bump
* TeamCity: fix go-tip builds on macOS/arm64
Co-authored-by: Michael Anthony Knyszek <mknyszek@google.com>
ConvertEvalScope() attempts to find the scope for the specified
goroutine id and frame index. If the goroutine that is found is nil,
then it falls back to the threads stack trace to find the scope.
This fix makes sure that the frame id is taken into account for
thread strack traces as well.
We told clients that further loading of variables can be done by
specifying a type cast using the address of a variable that we
returned.
This does not work for registerized variables (or, in general,
variables that have a complex location expression) because we don't
give them unique addresses and we throw away the compositeMemory object
we made to read them.
This commit changes proc so that:
1. variables with location expression divided in pieces do get a unique
memory address
2. the compositeMemory object is saved somewhere
3. when an integer is cast back into a pointer type we look through our
saved compositeMemory objects to see if there is one that covers the
specified address and use it.
The unique memory addresses we generate have the MSB set to 1, as
specified by the Intel 86x64 manual addresses in this form are reserved
for kernel memory (which we can not read anyway) so we are guaranteed
to never generate a fake memory address that overlaps a real memory
address of the application.
The unfortunate side effect of this is that it will break clients that
do not deserialize the address to a 64bit integer. This practice is
contrary to how we defined our types and contrary to the specification
of the JSON format, as of json.org, however it is also fairly common,
due to javascript itself having only 53bit integers.
We could come up with a new mechanism but then even more old clients
would have to be changed.
While Go still mostly uses DWARF v4, newer versions of GCC will emit
DWARF v5 by default. This patch improves support for DWARF v5 by parsing
the .debug_line_str section and using that during file:line lookups.
This patch only includes support for files, not directories.
Co-authored-by: Derek Parker <deparker@redhat.com>
* pkg/proc: implement support for hit count breakpoints
* update comment
* udpate hitcount comment
* update HitCond description
* add test for hit condition error
* respond to review
* service/dap: add support for hit count breakpoints
* use amendbps to preserve hit counts
* update test health doc
* fix failing test
* simplify hit conditions
* REmove RequestString, use name instead
* update backend_test_health.md
* document hit count cond
* fix tests
A RequestManualStop received while the target program is stopped can
induce a crash when the target is restarted.
This is caused by the phantom breakpoint detection that was introduced
in PR #2179 / commit e69d536.
Instead of always interpreting an unexplained SIGTRAP as a phantom
breakpoint memorize all possible unreported breakpoint hits and only
act on it when the thread hasn't moved from one.
Also clarifies the behavior of the halt command when it is received
while the target is stopped or in the process of stopping.
Adds the low-level support for watchpoints (aka data breakpoints) to
the native linux/amd64 backend.
Does not add user interface or functioning support for watchpoints
on stack variables.
Updates #279
There seems to be a problem where debugserver will leave a zombie
process instead of detaching correctly, we are sending the right
commands, it doesn't seem to be a problem with Delve.
This adds a workaround for the bug described at:
https://github.com/golang/go/issues/25841
Because dsymutil running on PIE does not adjust the address of
debug_frame entries (but adjusts debug_info entries) we try to do the
adjustment ourselves.
Updates #2346
- remove github workflow for testing macOS/amd64 that is now covered by
TeamCity
- fix DeepSource glob patterns to actually match what they are intended
to match (did the interpretation change?)
- disable some cgo tests on darwin/arm64
Delve represents registerized variables (fully or partially) using
compositeMemory, implementing proc.(*compositeMemory).WriteMemory is
necessary to make SetVariable and function calls work when Go will
switch to using the register calling convention in 1.17.
This commit also makes some refactoring by moving the code that
converts between register numbers and register names out of pkg/proc
into a different package.
* TeamCity: add linux/arm64/tip configuration
So that it can be tested when we make the next-version-support-branch.
* tests: disable failing cgo tests on arm64
* proc/core: off-by-one error reading ELF core files
core.(*splicedMemory).ReadMemory checked the entry interval
erroneously when dealing with contiguous entries.
* terminal,service,proc/*: adds dump command (gcore equivalent)
Adds the `dump` command that creates a core file from the target process.
Backends will need to implement a new, optional, method `MemoryMap` that
returns a list of mapped memory regions.
Additionally the method `DumpProcessNotes` can be implemented to write out
to the core file notes describing the target process and its threads. If
DumpProcessNotes is not implemented `proc.Dump` will write a description of
the process and its threads in a OS/arch-independent format (that only Delve
understands).
Currently only linux/amd64 implements `DumpProcessNotes`.
Core files are only written in ELF, there is no minidump or macho-o writers.
# Conflicts:
# pkg/proc/proc_test.go
Add a helper method for collecting line table file references that
does the correct thing for DWARF 5 vs DWARF 4 (in the latter case you
have an implicit 0 entry which is the comp dir, whereas in the former
case you do not). This is to avoid out-of-bounds errors when examining
the file table section of a DWARF 5 compilation unit's line table.
Included is a new linux/amd-only test that includes a precompiled C
object file with a DWARF-5 section that triggers the bug in question.
Fixes#2319
Changs TestClientServer_FullStacktrace and
Test1ClientServer_FullStacktrace to log more information, also removes
code from TestFrameEvaluation that could mask the error.
Updates #2231
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?).
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
