The initial implementation of the 'call' command required the
function call to be the root expression, i.e. something like:

	double(3) + 1

was not allowed, because the root expression was the binary operator
'+', not the function call.

With this change expressions like the one above and others are
allowed.

This is the first step necessary to implement nested function calls
(where the result of a function call is used as argument to another
function call).

This is implemented by replacing proc.CallFunction with
proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run
proc.(*EvalScope).EvalExpression in a different goroutine. This
goroutine, the 'eval' goroutine, will communicate with the main
goroutine of the debugger by means of two channels: continueRequest
and continueCompleted.

The eval goroutine evaluates the expression recursively, when
a function call is encountered it takes care of setting up the
function call on the target program and writes a request to the
continueRequest channel, this causes the 'main' goroutine to restart
the target program by calling proc.Continue.

Whenever Continue encounters a breakpoint that belongs to the
function call injection protocol (runtime.debugCallV1 and associated
functions) it writes to continueCompleted which resumes the 'eval'
goroutine.

The 'eval' goroutine takes care of implementing the function call
injection protocol.

When the expression is fully evaluated the 'eval' goroutine will
write a special message to 'continueRequest' signaling that the
expression evaluation is terminated which will cause Continue to
return to the user.

Updates #119

Before doing anything check that the version of Go is compatible with
the current version of Delve.
This will improve the error message in the case that  another change as
disruptive as Go1.11 dwarf compression, happens.

Add options to the stack command to read the goroutine ancestors.
Ancestor tracking was added to Go 1.12 with CL:
https://go-review.googlesource.com/c/go/+/70993/

Implements #1491

* *: use loglevel to control what gets logged instead of output redirection

This stops logrus from doing all the formatting just to discard it
immediately afterwards.

* logflags: replace default formatter of logrus

The default formatter of logrus emits logs in two different formats
depending on whether or not the output is going to a terminal. The
output format for non-terminals is indented to be machine readable, but
we mostly read logs ourselves and the excessive quoting makes that
format unreadable.
When outputting to terminals it uses ANSI escape codes unconditionally,
without checking whether the terminal it is connected to actually
supports colors.

This commit replaces the default formatter with a much simpler
formatter that always uses a more readable format, doesn't use colors
and places the key-value pairs at the beginning of the line (which is a
better match for how we use them).

* cmd/dlv: add command line options to redirect logs

Adds two options, --log-to-file and --log-to-fd, to redirect logs to a
file or to a file descriptor.

When one of those two options is specified the "API server listening
at:" message will also be redirected to the specified file/file
descriptor.
This allows clients that want to use the "API server listening at:"
message to do so even if they want to redirect the target's stdout to
another file or device.

Implements #1179, #1523

The repository is being switched from the personal account
github.com/derekparker/delve to the organization account
github.com/go-delve/delve. This patch updates imports and docs, while
preserving things which should not be changed such as my name in the
CHANGELOG and in TODO comments.

It was never true that return variables were in the inverse order.
Instead in Go1.11 return variables are saved in debug_info in an
arbitrary order and inverting them just happened to work for this
specific example.

This bug was fixed in Go 1.12, regardless we should attempt to
rearrange return variables anyway.

Instead of unconditionally returning all present goroutines,
GoroutinesInfo now allows specifying a range (start and count). In
addition to the array of goroutines and the error, it now also returns
the next goroutine to be processed, to be used as 'start' argument on
the next call, or 0 if all present goroutines have already been
processed.

This way clients can avoid eating large amounts of RAM while debugging
core dumps and processes with a exceptionally high amount of goroutines.

Fixes #1403

Add ability to evaluate variables on the scope of a deferred call's
argument frame.

Fix escape checking in function calls  and add a flag to disable it.

Support for position independent executables (PIE) on the native linux
backend, the gdbserver backend on linux and the core backend.
Also implemented in the windows native backend, but it can't be tested
because go doesn't support PIE on windows yet.

Replace the socket connection with an in-memory connection (created by net.Pipe) for non-headless uses of delve.
This is faster and more secure.

Fixes #1332

On macOS 10.14 Apple changed the command line tools so that system
headers now need to be manually installed.

Instead of adding one extra install step to the install procedure add a
build tag to allow compilation of delve without the native backend on
macOS. By default (i.e. when using `go get`) this is how delve will be
compiled on macOS, the make script is changed to enable compiling the
native backend if the required dependencies have been installed.

Insure that both configuration still build correctly on Travis CI and
change the documentation to describe how to compile the native backend
and that it isn't normally needed.

Fixes #1359

Adds -defer flag to the stack command that decorates the stack traces
by associating each stack frame with its deferred calls.

Reworks proc.next to use this feature instead of using proc.DeferPC,
laying the groundwork to implement #1240.

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

This pull request makes several changes to delve to allow headless
instancess that are started with the --accept-multiclient flag to
keep running even if there is no connected client. Specifically:

1. Makes a headless instance started with --accept-multiclient quit
    after one of the clients sends a Detach request (previously they
    would never ever quit, which was a bug).
2. Changes proc/gdbserial and proc/native so that they mark the
    Process as exited after they detach, even if they did not kill the
    process during detach. This prevents bugs such as #1231 where we
    attempt to manipulate a target process after we detached from it.
3. On non --accept-multiclient instances do not kill the target
    process unless we started it or the client specifically requests
    it (previously if the client did not Detach before closing the
    connection we would kill the target process unconditionally)
4. Add a -c option to the quit command that detaches from the
    headless server after restarting the target.
5. Change terminal so that, when attached to --accept-multiclient,
    pressing ^C will prompt the user to either disconnect from the
    server or pause the target process. Also extend the exit prompt to
    ask if the user wants to keep the headless server running.

Implements #245, #952, #1159, #1231

Implements structured logging via Logrus. This gives us a logger per
boundry that we care about, allowing for easier parsing of logs if users
have more than one log option enabled. Also, cleans up a lot of
conditionals in the code by simply silencing the logger at creation as
opposed to conditionally logging everywhere.

Displays the return values of the current function when we step out of
it after executing a step, next or stepout command.

Implementation of this feature is tricky: when the function has
returned the return variables are not in scope anymore. Implementing
this feature requires evaluating variables that are out of scope, using
a stack frame that doesn't exist anymore.

We can't calculate the address of these variables when the
next/step/stepout command is initiated either, because between that
point and the time where the stepout breakpoint is actually hit the
goroutine stack could grow and be moved to a different memory address.

The rr backend doesn't report the exit status (the argument of the W
packet seems to always be 0).

Fixes #1067

Fixes #940

go1.9 no longer needs "linkmode internal" on windows.

Fixes #755
Fixes #477
Fixes #631

Can't get the trace directory from the server after we disconnect from
it.

If the user tries to list the contents of a function pointer but
forgets the '*' operator the location lookup will fail and result in a
unhelpful "location not found" error.

Instead if the location lookup fails we should try interpreting the
locspec as if it was preceded by '*'.

If one of the expressions that are automatically evaluated when a
breakpoint is hit can't be evaluated breakpoint information collection
should continue and the error should be returned for that specific
expression instead of the whole command.

* Fix various issues detected by megacheck

I've ran honnef.co/go/tools/cmd/megacheck and fixed a few of the
things that came up there.

* Cleanup using Gogland

A next/step/stepout command could hit a normal breakpoint, decorated
with a list of variables to evaluate, if that happens the variable
should be evaluated just as if the breakpoint was hit by a continue.

Implements #727

Go recently introduced proposal tags to their version tags, we
are simply allowing delve to handle it appropriately.

See:
https://github.com/golang/go/commit/0954fdd51e390e209317d4652d7effc15512fd50

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.

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.

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.

* dwarf/line: bugfix: not all values of the state machine can be used

According to DWARF Version 3 Section 6.2 "Line Number Information" not
all the values transversed by the line numbers state machine are valid
instructions, only the ones after a "special opcode", after the
standard opcode DW_LNS_copy and the extended opcode
DW_LINE_end_sequence.

DWARF3 describes this by specifying that only the opcodes listed above
"append a row to the matrix".

Additionally the implementation of DW_LNS_const_add_pc was wrong.

Fixes #664

* dwarf/line: fixed test failing with go1.8

* service/test: fix prologue detection tests

The conditions about which function prologue is emitted by the compiler
changed in go1.8, changed the test program so that callme2 will still
have a prologue under go1.8.

* service/test: fix step test

compilation units are linked in a different order under go1.8 so the
code of 'fmt' is no longer located after 'main' in the executable,
changed the tests so that they don't rely on this assumption anymore.

* proc: change runtime.Breakpoint support for go1.8

Before 1.8 it was sufficient to step twice to exit a
runtime.Breakpoint(), but go 1.8 added frame pointer tracking to small
functions making runtime.Breakpoint longer.
This changes runtime.Breakpoint handling in Continue to single step as
many times as are needed to exit runtime.Breakpoint.

* proc/test: fix TestIssue561 for go1.8

* terminal: fixed typo.

* debugger: bugfix: when restaring use new process to FindFileLocation