RequestManualStop will run concurrently with trapWait, since one writes
dbp.halt and the other reads it dbp.halt should be protected by a
mutex.

Updates #830

The condition that causes waitFast to fail can not happen in addThread
and halt so we don't need to call the slower wait.

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

- move native backend to pkg/proc/native
- move gdbserver backend to pkg/proc/gdbserial
- move core dumps backend to pkg/proc/core

* 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

* proc: Added trace benchmark

Results:

BenchmarkTrace-4   	    5000	  36195899 ns/op

* proc/linux: faster single step implementation.

BenchmarkTrace-4   	    5000	   2093271 ns/op

* proc: Cache function debug_info entries to speed up variable lookup.

BenchmarkTrace-4   	    5000	   1864846 ns/op

* proc/variables: Optimize FunctionArguments by prefetching frame

BenchmarkTrace-4   	    5000	   1815795 ns/op

* proc/variables: optimized parseG

BenchmarkTrace-4   	   10000	    712767 ns/op

* service/debugger: Restore breakpoints using file:line on restart

Restoring by address can cause the breakpoint to be inserted in the
middle of an instruction if the executable file has changed.

* terminal: Warn of stale executable when printing source

* proc: Add `wd` to Launch

This change adds the `wd` arg which specify working directory of the
program.

Fixes #295

* service/debugger: Add `Wd` field to debugger.Config

This change adds the `Wd` field which specify working directory of the
program launched by debugger.

Fixes #295

* service: Add `Wd` to service.Config

This change adds the `Wd` field which specify working directory of the
program debugger will launch.

Fixes #295

* cmd/dlv: Add `Wd` flag

This change adds `Wd` flag which specify working directory of the
program which launched by debugger.

Fixes #295

* only set the Linux working directory if it is set,
stub out param in darwin and windows

* set working directory for Windows
https://godoc.org/golang.org/x/sys/windows#CreateProcess
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

* Windows workingDir must be an *uint16

* attempt to chdir on darwin via @yuntan

* proc/exec_darwin.c: fix working directory for darwin

* Add tests to check if working directory works.
* Fix darwin implementation of fork/exec, which paniced if
  child fork returned.

* cmd, service: rename Wd to WorkingDir

fix #531

Fixes flakiness of TestCmdLineArgs.

Patch https://go-review.googlesource.com/23085 has been merged so we
can go back to using golang.org/x/debug/.

This provides a better error message when the user tries to run dlv
debug on a directory that does not contain a main package, when `dlv
exec` is used with a source file.

Additionally the architecture of the executable is checked as suggested
by @alexbrainman in #443.

Fixes #509

* tests: update to cope with go1.7 SSA compiler

* de-vendored golang.org/x/debug/dwarf

We need our own tweaked version

* dwarf/debug/dwarf: always use the entry's name attribute

Using the name attribute leads to better type names as well as fixes
inconsistencies between 1.5, 1.6 and 1.7.

* proc: Updated loadInterface to work with go1.7

go1.7 changed the internal representation of types, removing the string
field from runtime._type.
Updated loadInterface to use the new str field.

On linux kernel 2.6.x, the Trace/Stop status is 'T'

Fixes #209

Fixes #419 (partial)

This patch modifies the `step` command to step to the next source line,
stepping into any function encountered along the way.

Fixes #360

Typedefs that resolve to slices are not recorded in DWARF as typedefs
but instead as structs in a way that there is no way to know they
are really slices using debug/dwarf.
Using golang.org/x/debug/dwarf instead this problem is solved and
as a bonus some types are printed with a nicer names: (struct string
→ string, struct []int → []int, etc)

 Fixes #356 and #293

Fixes #198.

resume loops in continueOnce moved to a OS specific resume function,
this makes the problem easier to deal with and seems to be more
appropriate to a windows port given what transpired from discussion
of Pull Request #276

Breakpoints are skipped either because:
1. when multiple breakpoints are hit simultaneously only one is
processed
2. a thread hits a breakpoint while another thread is being
singlestepped over the breakpoint.

Additionally fixed a race condition between Continue and tracee
termination.

Only used under Linux, no need to have it available on Process itself.

Prevents a lot of goroutines hanging around, especially when running
tests.

/proc/pid/stat needs more complex parsing

Fixes #239

During process termination we seem to receive notifications of new
threads that die before we can add them, ignore them

Only use software breakpoints for now. The reasoning is because it
complicates the code without justification, and is only supported on
Linux. Eventually, once watchpoints are properly implemented we will
revive some of this code. Also, if it is ever necessary to actually set
a hw breakpoint we can revive that code as well.

All future versions of this code will include support for OSX before
being merged back in.

This patch aims to improve how Delve tracks the current goroutine,
especially in very highly parallel programs. The main spirit of this
patch is to ensure that even in situations where the goroutine we care
about is not executing (common for len(g) > len(m)) we still end up back
on that goroutine as a result of executing the 'next' command.

We accomplish this by tracking our original goroutine id, and any time a
breakpoint is hit or a threads stops, we examine the stopped threads and
see if any are executing the goroutine we care about. If not, we set
'next' breakpoint for them again and continue them. This is done so that
one of those threads can eventually pick up the goroutine we care about
and begin executing it again.

We're not dealing with a debugged process having its own controlling
terminal at this point, so no need to make the new process a session
leader. Simply making the process a group leader will suffice for our
purposes at the moment.