* pkg/proc: Introduce Target

* pkg/proc: Remove Common.fncallEnabled

Realistically we only block it on recorded backends.

* pkg/proc: Move fncallForG to Target

* pkg/proc: Remove CommonProcess

Remove final bit of functionality stored in CommonProcess and move it to
*Target.

* pkg/proc: Add SupportsFunctionCall to Target

Specifically, make sure that both DebugActiveProcess and
WaitForDebugEvent Windows APIs are executed on the same thread.

Otherwise WaitForDebugEvent fails with ERROR_INVALID_HANDLE as per its
documentation

https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-waitfordebugevent

'... Only the thread that created the process being debugged can call
WaitForDebugEvent. ...'

Fixes #1825

When attaching to a process in linux ElfUpdateSharedObjects will be
called for the first time during the call to updateThreadList,
unfortunately it won't do anything because the dynamic section of the
base elf executable needs to have been read first and that's done when
we initialize the BinaryInfo object (which happens later during the
call to initialize).

* move firstPCAfterPrologueDisassembly() and checkPrologue() out of arch independent.
* s/do not/does not/ (for all tests)

arm64 use hardware breakpoint, and it will not set PC to the next instruction like amd64. Let adjustPC always fasle in arm64, in case of infinite loop.

* delve now can be built to arm64-arch and running on linux-arm64 OS.
* arm64 general-purpose registers have completed.
* arm64 disasm has completed.
Co-authored-by: Ntykcd996 <tang.yuke@zte.com.cn>
Co-authored-by: Nhengwu0 <wu.heng@zte.com.cn>

As proc/native is arch related, it should move some functions to arch-relate file. And this patch can help us to separate the architecture code, make code tidy. So that the merge of arm64 code later will not cause chaos.(#118)

the tracee may coredumped after detach: trace/breakpoint trap (core dumped).

* proc/linux: do not route signals to threads while stopping

While we are trying to stop the process we should not route signals
sent to threads because that will result in threads being resumed.
Also keep better track of which threads are stopped.

This fixes an incompatibility with Go 1.14, which sends a lot of
signals to its threads to implement non-cooperative preemption,
resulting in Delve hanging waiting for an already-stopped thread to
stop.

In principle however this bug has nothing to do with Go 1.14 and could
manifest in any instance of high signal pressure.

* Makefile: discard stderr of "go list"

In module mode "go" will print messages about downloading modules to
stderr, we shouldn't confuse them for the real command output.

Fixes a case of breakpoint confusion on resume caused by having two
breakpoints one byte apart. This bug can cause the target program to
resume execution a single byte inside an instruction and crash either
with SIGILL or a SIGSEGV, or misbehave (depending on how the truncated
instruction is decoded).

native.(*Thread).StepInstruction should call FindBreakpoint using
adjustPC==false because at that point the PC of the thread should
already have been adjusted (and it has been).

proc.Next and proc.Step will call, after setting their temp
breakpoints, curthread.SetCurrentBreakpoint. This is intended to find
if one of the newly created breakpoints happens to be at the same
instruction that curthread is stopped at.
However SetCurrentBreakpoint is intended to be called after a Continue
and StepInstruction operation so it will also detect if curthread is
stopped one byte after a breakpoint.
If the instruction immediately preceeding the current instruction of
curthread happens to:
 1. have one of the newly created temp breakpoints
 2. be one byte long
SetCurrentBreakpoint will believe that we just hit that breakpoint and
therefore the instruction should be repeated, and thus rewind the PC of
curthread by 1.

We should distinguish between the two uses of SetCurrentBreakpoint and
disable the check for "just hit" breakpoints when inappropriate.

Fixes #1656

If we return ErrProcessExited we should also set exited to true.

* FreeBSD initial support

* first code review fixes

* regs slice upd

* execPtraceFunc wrap

* disabled concurrency tests
fixed kill() issue

* disabled concurrency tests
fixed kill() issue

* cleanup vendor related code

* cleanup ptrace calls

* vendoring latest changes

* Revert "vendoring latest changes"

This reverts commit 833cb87b

* vendoring latest changes

* requested changes

RestoreRegisters on linux would also restore FS_BASE and GS_BASE, if
the target goroutine migrated to a different thread during the call
injection this would result in two threads of the target process
pointing to the same TLS area which would greatly confuse the target
runtime, leading to fatal panics with nonsensical stack traces.

Other backends are unaffected:

- native/windows doesn't store the TLS in the same CONTEXT struct as
  the other register values.
- native/darwin doesn't support function calls (and wouldn't store the
  TLS value in the same struct)
- gdbserial/rr doesn't support function calls (because it's a
  recording)
- gsdbserial/lldb extracts the value of TLS by executing code in the
  target process.

Adds initial support for plugins, this is only the code needed to keep
track of loaded plugins on linux (both native and gdbserial backend).

It does not actually implement support for debugging plugins on linux.

Updates #865

Fixes #1493

This file should be located elsewhere (on the OSX host, I believe) and
as such does not beed to be checked in here.

Fixes #1460

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.

PTRACE_GETREGSET was added in Linux 2.6.34, running this request in an
older kernel will report EIO, as documented on the manpage.

Fixes #1197

Move windows register handling code to winutil package in preparation
for using it in proc/core to read minidump files.

If proc.Step encounters a CALL instruction that points to an address
that isn't associated with any function it should still follow the
CALL.

The circumstances creating this problem do not normally occur, it was
encountered in the process of fixing a bug created by Go1.12.

This patch is a slight refactor to share more code used for genericprocess initialization. There will always be OS/backend specificinitialization, but as much as can be shared should be to preventduplicating of any logic (setting internal breakpoints, loading bininfo,etc).

Adds a config file option to allow specifying a list of directories to
search in when looking for seperate external debug info files.

Fixes #1353

The linux version of proc/native and proc/core contained largely
overlapping implementations of the register handling code, deduplicate
it by moving it into proc/linutil.

Some libraries (for example steam_api64.dll) will send this exception
code to set the thread name on Microsoft VisualC.
In theory it should be fine to send the exception back to the target,
which is responsible for setting a handler for it, in practice in some
cases (steam_api64.dll) this will crash the program. So we'll mask it
instead.

Fixes #1383

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.

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

Refactors some code, adds a bunch of docstrings and just generally fixes
a bunch of linter complaints.

Fncall.go was written with the assumption that the object returned by
proc.Thread.Registers does not change after we call
proc.Thread.SetPC/etc.

This is true for the native backend but not for gdbserial. I had
anticipated this problem and introduced the Save/SavedRegisters
mechanism during the first implementation of fncall.go but that's
insufficient.

Instead:

1. clarify that the object returned by proc.Thread.Registers could
   change when the CPU registers are modified.
2. add a Copy method to Registers that returns a copy of the registers
   that are guaranteed not to change when the CPU registers change.
3. remove the Save/SavedRegisters mechanism.

This solution leaves us the option, in the future, to cache the output
of proc.(Thread).Registers, avoiding a system call every time it's
called.

If we send a process to foreground while the headless instance may get
a SIGTTOU/SIGTTIN, if not ignored this signal will stop the headless.
It's not clear why this only happens the second time we do this but
that's how it is.

Also removes the direct syscall to TIOCSPGRP and lets the go runtime do
it instead.

Fixes #1279

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

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.

Add a new method "Common" to proc.Process that returns a pointer to a
struct that pkg/proc can use to store its things, independently of the
backend.

This is used here to replace the AllGCache typecasts, it will also be
used to store the return values of the stepout breakpoint and the state
for injected function calls.

Change the linux verison of proc/native and proc/gdbserial (with
debugserver) so that they let the target process use the terminal when
delve is launched in headless mode.

Windows already worked, proc/gdbserial (with rr) already worked.
I couldn't find a way to make proc/gdbserial (with lldb-server) work.

No tests are added because I can't think of a way to test for
foregroundness of a process.

Fixes #65