Implementing proc.Process.Running in a thread safe way is complicated
and nothing actually uses it besides tests, so we are better off
rewriting the tests without Running and removing it.
In particular:
* The call to d.target.Running() in service/debugger/debugger.go
(Restart) can never return true because that line executes while
holding processMutex and all continue operations are also executed
while holding processMutex.
* The call to dbp.Running() pkg/proc/native/proc.go (Detach) can never
return true, because it's only called from
debugger.(*Debugger).detach() which is also always called while
holding processMutex.
Since some tests are hard to write correctly without Process.Running a
simpler interface, Process.NotifyResumed, is introduced.
Fixes#830
Before this commit our temp breakpoints only checked that we would stay
on the same goroutine.
However this isn't enough for recursive functions we must check that we
stay on the same goroutine AND on the same stack frame (or, in the case
of the StepOut breakpoint, the previous stack frame).
This commit:
1. adds a new synthetic variable runtime.frameoff that returns the
offset of the current frame from the base of the call stack.
This is similar to runtime.curg
2. Changes the condition used for breakpoints on the lines of the
current function to check that runtime.frameoff hasn't changed.
3. Changes the condition used for breakpoints on the return address to
check that runtime.frameoff corresponds to the previous frame in the
stack.
4. All other temporary breakpoints (the step-into breakpoints and defer
breakpoints) remain unchanged.
Fixes#828
Debugserver does not work as documented, "--" needs to be specified to
pass arguments to the target process (but only if it's an argument that
starts with a dash).
Fixes#839
While implementing the gdbserial backend everything was changed to call
Detach to "close" a process so that gdbserial could do its clean up in
a single place. However the native implementation of Detach does not
actually kill processes we launched.
Fixes#821
- moved target.Interface into proc as proc.Process
- rename proc.IThread to proc.Thread
- replaced interfaces DisassembleInfo, Continuable and
EvalScopeConvertible with Process.
- removed superfluous Gdbserver prefix from types in the gdbserial
backend.
- removed superfluous Core prefix from types in the core backend.
* proc: Refactor stackIterator to use memoryReadWriter and BinaryInfo
* proc: refactor EvalScope to use memoryReadWriter and BinaryInfo
* proc: refactor Disassemble to use memoryReadWriter and BinaryInfo
* proc: refactor BinaryInfo part of proc.Process to own type
The data structures and associated code used by proc.Process
to implement target.BinaryInfo will also be useful to support a
backend for examining core dumps, split this part of proc.Process
to a different type.
* proc: compile support for all executable formats unconditionally
So far we only compiled in support for loading the executable format
supported by the host operating system.
Once support for core files is introduced it is however useful to
support loading in all executable formats, there is no reason why it
shouldn't be possible to examine a linux coredump on windows, or
viceversa.
* proc: bugfix: do not resume threads on detach if killing
* Replace BinaryInfo interface with BinInfo() method returning proc.BinaryInfo
Detach did not work for processes we attach to via PID.
Linux: we were only detaching from the main thread, all threads are
detached independently
Windows: we must resume all threads before detaching.
macOS: still broken.
Updates #772
Stack barriers were removed in Go 1.9, and thus code that
expected various stack-barrier-related symbols to exist
does not find them. Check for their absence and do not
crash when they are missing. Disable stack-barrier-handling
test for 1.9 and beyond.
Fixes#754.
The rest of the code uses Detach to "close" a proc.Process, the tests
should do the same.
Any cleanup that proc.Process needs to do can then be put inside Detach
and the tests will run it.
It was possible for TestStepParked to pick a runtime goroutine and
attempt to step it. Nothing guarantees that a goroutine other than the
ones we are using to run the code would actually ever resume before the
end of the program.
This makes the test more discerning in its choice of goroutines.
On Windows we can sometimes encounter threads stopped in locations for
which we do not have entries in debug_frame.
These cases seem to be due to calls to Windows API in the go runtime,
we can still produce a (partial) stack trace in this circumstance by
following frame pointers (starting with BP).
We still prefer debug_frame entries when available since go functions
do not have frame pointers before go1.8.
Sometimes windows will send us events about breakpoints we have
already removed from the code despite the fact that we go to great
lengths to avoid this already.
Change waitForDebugEvent to check that when we receive a breakpoint
event the corresponding memory actually contains an INT 3
instruction, if it doesn't ignore the event and restart the thread.
Changes to the GC in 1.8 make this test fail because the GC isn't
inserting stack barriers into our test program anymore. This isn't the
same thing as being unable to print stacktraces in presence of stack
barriers so the test shouldn't fail.
