- 31 8月, 2018 2 次提交
-
-
由 aarzilli 提交于
-
由 aarzilli 提交于
Fncall.go was written with the assumption that the object returned by proc.Thread.Registers does not change after we call proc.Thread.SetPC/etc. This is true for the native backend but not for gdbserial. I had anticipated this problem and introduced the Save/SavedRegisters mechanism during the first implementation of fncall.go but that's insufficient. Instead: 1. clarify that the object returned by proc.Thread.Registers could change when the CPU registers are modified. 2. add a Copy method to Registers that returns a copy of the registers that are guaranteed not to change when the CPU registers change. 3. remove the Save/SavedRegisters mechanism. This solution leaves us the option, in the future, to cache the output of proc.(Thread).Registers, avoiding a system call every time it's called.
-
- 14 7月, 2018 1 次提交
-
-
由 aarzilli 提交于
Implements the function call injection protocol introduced in go 1.11 by https://go-review.googlesource.com/c/go/+/109699. This is only the basic support, see TODO comments in pkg/proc/fncall.go for a list of missing features. Updates #119
-
- 07 3月, 2018 3 次提交
-
-
由 aarzilli 提交于
Windows and macOS aren't using this field so move it to the os-specific thread struct and remove it from everything except linux.
-
由 aarzilli 提交于
-
由 aarzilli 提交于
If a breakpoint is hit close to process death on a thread that isn't the group leader the process could die while we are trying to stop it. This can be easily reproduced by having the goroutine that's executing main.main (which will almost always run on the thread group leader) wait for a second goroutine before exiting, then setting a breakpoint on the second goroutine and stepping through it (see TestIssue1101 in proc_test.go). When stepping over the return instruction of main.f the deferred wg.Done() call will be executed which will cause the main goroutine to resume and proceed to exit. Both the temporary breakpoint on wg.Done and the temporary breakpoint on the return address of main.f will be in close proximity to main.main calling os.Exit() and causing the death of the thread group leader. Under these circumstances the call to native.(*Thread).waitFast in native.(*Thread).halt can hang forever due to a bug similar to https://sourceware.org/bugzilla/show_bug.cgi?id=12702 (see comment in native.(*Thread).wait for an explanation). Replacing waitFast with a normal wait work in most circumstances, however, besides the performance hit, it looks like in this circumstances trapWait sometimes receives a spurious SIGTRAP on the dying group leader which would cause the subsequent call to wait in halt to accidentally reap the process without noting that it did exit. Instead this patch removes the call to wait from halt and instead calls trapWait in a loop in setCurrentBreakpoints until all threads are set to running=false. This is also a better fix than the workaround to ESRCH error while setting current breakpoints implemented in 94b50d. Fixes #1101
-
- 02 5月, 2017 1 次提交
-
-
由 Alessandro Arzilli 提交于
Fixes #809
-
- 22 4月, 2017 1 次提交
-
-
由 aarzilli 提交于
- move native backend to pkg/proc/native - move gdbserver backend to pkg/proc/gdbserial - move core dumps backend to pkg/proc/core
-
- 19 4月, 2017 2 次提交
- 07 4月, 2017 1 次提交
-
-
由 Alessandro Arzilli 提交于
* 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
-
- 09 2月, 2017 2 次提交
-
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
- 22 10月, 2016 1 次提交
-
-
由 Alessandro Arzilli 提交于
* proc: changed windows backend to deal with simultaneous breakpoints * bugfix: forgot to add windowsPrologue3 to the prologues list in e4c7df14 * Tolerate errors returned by Stacktrace in TestStacktraceGoroutine. * bugfix: proc: propagate debug events we don't cause back to the target process Fixes: #594 * proc: fixed TestStepConcurrentPtr Implementation of nextInProgress was wrong.
-
- 30 5月, 2016 1 次提交
-
-
由 Derek Parker 提交于
-
- 28 2月, 2016 1 次提交
-
-
由 aarzilli 提交于
Fixes #414
-
- 19 2月, 2016 1 次提交
-
-
由 Alex Brainman 提交于
Unrelated to conversion, I have also changed (*Thread).readMemory to return only first count bytes of memory just as advised by ReadProcessMemory. Fixes #409 Fixes #412 Fixes #416
-
- 21 1月, 2016 1 次提交
-
-
由 Luke Hoban 提交于
Fixes #198.
-