- 11 7月, 2015 2 次提交
-
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
- 10 7月, 2015 5 次提交
-
-
由 Derek Parker 提交于
We do not need to verify a current breakpoint, nor do a redundant check on whether we have been asked to manually halt. Assume trapWait has done its due diligence and stop the world once it returns.
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
Also, kill whitespace to make code appear more as a singular block for readability.
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
Major source cleanup, still not finished. Removes gross control flow.
-
- 09 7月, 2015 2 次提交
-
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
- 08 7月, 2015 4 次提交
-
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
Instead of fighting against the normal flow, just signal a SIGTRAP and let the existing flow handle it, as long as we set the halt flag correctly the system should halt.
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
- 07 7月, 2015 2 次提交
-
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
- 04 7月, 2015 3 次提交
-
-
由 aarzilli 提交于
-
由 Derek Parker 提交于
Fixes #95
-
由 Derek Parker 提交于
-
- 02 7月, 2015 1 次提交
-
-
由 Derek Parker 提交于
-
- 01 7月, 2015 1 次提交
-
-
由 Derek Parker 提交于
* Cleanup comments * Cleanup naming in certain instances * Modify stacktrace to return current location
-
- 30 6月, 2015 1 次提交
-
-
由 aarzilli 提交于
-
- 29 6月, 2015 2 次提交
-
-
由 Derek Parker 提交于
-
由 aarzilli 提交于
additionally fixes a bug when Detach is called on an exiting/exited thread: dbp.CurrentThread could point to a thread that has already been removed from dbp.Threads by trapWait which will lead to a nil pointer dereference caused proc.Process.clearBreakpoint getting nil from dbp.Threads[tid]
-
- 28 6月, 2015 3 次提交
-
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
由 aarzilli 提交于
-
- 27 6月, 2015 4 次提交
-
-
由 Derek Parker 提交于
Fixes #154
-
由 Derek Parker 提交于
-
由 aarzilli 提交于
On a thread that's leader of its group, that is ptraced and that was survived by its children.
-
由 aarzilli 提交于
-
- 26 6月, 2015 3 次提交
-
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
- 25 6月, 2015 4 次提交
-
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
For hardware breakpoints we have to set them on every thread. It could be the case that another thread is running. Stop it first, set the breakpoint, then continue it.
-
- 24 6月, 2015 1 次提交
-
-
由 Derek Parker 提交于
Instead of maintaining two separate client / server implementations, maintain only the more lightweight JSON-RPC service. The reasoning behind the merging of the original HTTP service was ease of tooling, in other words low barrier of entry for external clients (editor integrations, etc...). I believe the JSON-RPC solution still satisfies that constraint while have the advantage of being a more lightweight solution. HTTP, while highly supported in most modern languages, carries with it too many features we would never take advantage of. The RPC architecture seems a more natural approach. The infrastructure set up during the initial HTTP service implementation was leveraged in the JSON-RPC implementation, so if any of those original authors are reading this commit message: thank you for that work, it was not in vain even if though the original HTTP service is not being removed.
-
- 22 6月, 2015 2 次提交
-
-
由 Derek Parker 提交于
-
由 Derek Parker 提交于
-