According to https://golang.org/cmd/go/#hdr-Test_packages
service_test is more appropriate becuase this directory contains
no non-test code and the intention is to compile these *_test.go
files as a separate package and link/run with the main test package.

- always print a header with the path to the file being displayed
- always evaluate the linespec argument, even if a scope prefix is present

Fixes #711, #713

Expressions such as:

 frame 0    list
 frame   0   list
 on abreakpoint     print x
 goroutine    1    frame     0     list

should all execute correctly

Fixes #712

GdbserverProcess does its cleanup in Detach we need to always call
that function.

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.