Core files contain a variety of memory mappings either to files or
anonymous regions stored in the core file. These regions can overlap, so
figuring out what exactly to read can be tricky. This commit contains
a data structure, SplicedMemory, which accumulates mappings and reads
from the correct sources.

* pkg/proc: use golang.org/x/arch/x86/x86asm

instead of rsc.io/x86/x86asm

* pkg/dwarf: migrate to github.com/pkg/profile

from github.com/davecheney/profile

* scripts: keep script go files from being considered for the build

scripts/gen-*.go files are scripts for generating documentation
files and don't follow the typical Go package layout. Expected
usage is like

   go run scripts/gen-cli-docs.go

* vendor: update vendored packages

There were many changes in delve, and go tool chains since last
vendored package update. I just rerun godpes from scratch.

$ rm vendor/*
$ rm Godeps/Godeps.json
$ go list ./... | grep -v /vendor/ | grep -v /scripts/ | go get -u -t
$ go get -u github.com/mattn/go-colorable
$ go get -u github.com/mattn/go-isatty
$ go list ./... | grep -v /vendor/ | grep -v /scripts/ | godeps save

* proc: Refactor stackIterator to use memoryReadWriter and BinaryInfo

* proc: refactor EvalScope to use memoryReadWriter and BinaryInfo

* proc: refactor Disassemble to use memoryReadWriter and BinaryInfo

Fixes #783

* 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

When running interactive command in gdb, it will remove beginning space,
so do the same for dlv, which will be more convient for user

* cmd/dlv: fall back to go env GOPATH when GOPATH envvar is unset.

Since Go 1.8, GOPATH environment variable has a default value if the
environment variable is unset so not setting GOPATH is perfectly ok.
Depend on `go env` command to query Go related environment variable.

* build: update references to moved packages

We only use Registers.Get besides for evaluating the argument of a CALL
instruction so this doesn't matter in practice, but it's still wrong.

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.

One of those goroutines could also conceivably be stopped on line 8.

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.

Dropping test coverage for Go 1.6.

Closes #741

The test in question tries to 'next' over a call to wg.Done, this is
not guaranteed to succeed, if the goroutine gets suspended after
wg.Done has notified the waiting group but before returning to
main.dostuff the program could quit before the goroutine is resumed.

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.

The PC we have is relative to the first instruction after the CALL
instruction currently being executed.

Anyone watching a disassembly will understand what's happening if we
report the return PC, but reporting the first PC of the current line is
useless and confusing.

Fixes #732

loadValue didn't react correctly to pointer loops going through
slice -> interface{} -> slice or pointer -> interface{} -> pointer.

Fixes #729

Signed-off-by: NKoichi Shiraishi <zchee.io@gmail.com>

Under currently undetermined circumstances we encounter a map type that
has a malformed buckets, oldbuckets or overflow field.
Check the type of buckets, oldbuckets and overflow before using them.

Fixes #685

* service/rpccommon: fixed typo

* proc: test parseG while target is in runtime.deferreturn

runtime.deferreturn will change the value of curg._defer.fn in such a
way that if the target is stopped at just the right instruction it
may crash an incorrect implementation of parseG

* proc/stack: handle stack barriers correctly

Correctly handle stack barriers insterted during garbage collection.

We are already doing this in GoroutinesInfo we should be doing it for
GetG. The main consequence of not doing this is that the CurrentLoc of
DebuggerState.SelectedGoroutine is out of date compared to the location
of the thread running it.

* 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