Avoid crashing with nil pointer dereference, signal error instead.

Fixes #1720

Splits the code that loads function information from debug_info into
multiple functions.
This makes the changes needed to implement logical breakpoints easier
to make.

The fix for #1428 was buggy, partly because I communicated poorly. Sorry
about that.

The size of the TLS segment should be padded such that TLS addresses
are congruent in the file to where they will end up memory, i.e.
(tlsoffset%align) == (vaddr%align). In most cases, vaddr will be aligned
and it won't matter, but if not then simply aligning the end of the
segment is incorrect. This should be right.

(For the record, the current rounding logic is working in bits, but
PtrSize is in bytes, so it wasn't working as originally intended
either.)

They are irrelevant and confusing.

Intent here is to bring optargorder up to date with delve
and keep it in sync (and to use optargorder to help monitor
compiler output for debugging quality regressions).

Remove `initialized` member in favor of just deriving the information it
represented.

The methods for the BinaryInfo and Image structs were spread around in
multiple files. This patch just brings them all under one file.

This is going towards untangling proc in order to clean it up.

* 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

Support for bulk queries makes the DWARF quality checker
(github.com/dr2chase/dwarf-goodness/cmd/dwarf-goodness)
run much more efficiently (replace quadratic cost with
linear).

Also fixes findCompileUnitForOffset which was broken in some edge cases
(when looking up an offset inside the last child of the compilation
unit) which don't happen in normal executables (we only look up types, and those
are always direct childs of compile units).

Instead of reading partial units as we see them skip them entirely and
then re-read them when they are imported, directly into the destination
compile unit.

This avoids a lot of duplicate code in the loadDebugInfoMaps function
and will simplify implementing logical breakpoints and support for the
new DW_AT_go_package_name attribute added in Go 1.13.

The current wording is confusing - the file exists and the line exists, so what is the problem? I suspect this ambiguity is behind #1496 and likely others.

Also I updated the style to return values like the rest of the code in the file, which is also more readable (IMO and per https://github.com/golang/go/wiki/CodeReviewComments#named-result-parameters)

This change splits the BinaryInfo object into a slice of Image objects
containing information about the base executable and each loaded shared
library (note: go plugins are shared libraries).

Delve backens are supposed to call BinaryInfo.AddImage whenever they
detect that a new shared library has been loaded.

Member fields of BinaryInfo that are used to speed up access to dwarf
(Functions, packageVars, consts, etc...) remain part of BinaryInfo and
are updated to reference the correct image object. This simplifies this
change.

This approach has a few shortcomings:

1. Multiple shared libraries can define functions or globals with the
   same name and we have no way to disambiguate between them.

2. We don't have a way to handle library unloading.

Both of those affect C shared libraries much more than they affect go
plugins. Go plugins can't be unloaded at all and a lot of name
collisions are prevented by import paths.

There's only one problem that is concerning: if two plugins both import
the same package they will end up with multiple definition for the same
function.
For example if two plugins use fmt.Printf the final in-memory image
(and therefore our BinaryInfo object) will end up with two copies of
fmt.Printf at different memory addresses. If a user types
  break fmt.Printf
a breakpoint should be created at *both* locations.
Allowing this is a relatively complex change that should be done in a
different PR than this.

For this reason I consider this approach an acceptable and sustainable
stopgap.

Updates #865

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 #1481

Do not mention external debug info files when the problem might just be
that the executable was stripped.

Fixes #1471

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.

The size of the TLS memory arena needs to be aligned to pointer sized
boundaries on 86x64 architectures, otherwise some programs using cgo
will not have the correct offset for the g struct.

No tests because reproducing this problem depends on behavior of the
GNU ld linker caused by unclear influences.

Fixes #1428.

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

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.

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

Normally variables that have a named struct as a type will get a
typedef entry as their type, sometimes however the Go linker will
decide to use the DW_TAG_structure_type entry instead.

For consistency always wrap a struct type into a typedef when we are
creating a new variables (see comment in newVariable for exceptions).

This fixes a bug where it would be impossible to call methods on a
global variable.

This patch makes it so inlined functions are returned in the
function
list, and also allows users to set breakpoints on the call site of
inlined functions.

Fixes #1261

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

Go1.11 switched to the zlib-gnu compression format for debug sections.
Change proc and and a test in dwarf/line to support this change.

Also deletes some dead code from pkg/proc/bininfo.go that hadn't been
used in a long time.

To save disk space, some distributions strip the debugging information
from the binaries, putting it in separate files, usually distributed in
separate packages.

To locate the file containing the debug information for a certain
binary, an ELF note named ".note.gnu.build-id" is added to the latter,
which contains a header and a build identification. This identification
can be used to compose a path with this form:

/usr/lib/debug/.build-id/BUILDID[:2]/BUILDID[2:].debug

With this patch, if Delve can't find the debug information in the main
binary, it'll try to locate and parse ".note.gnu.build-id", to compose
and attempt to open a path with the format described above.

Fixes #1206

go1.11 adds a new extended attribute to all type DIEs containing the
address of the corresponding runtime._type struct, use this attribute
to find the DIE of the concrete type of interface variables when
available.

The offset of G changed in go1.11 from 0x8a0 to 0x30. See:
https://github.com/golang/go/issues/23617

'dwz' is a tool that reduces the size of DWARF sections by
deduplicating symbols. The deduplicated symbols are moved from their
original 'compile unit' to a 'partial unit', which is then referenced
from its original location with an 'imported unit' tag.

In the case of Go binaries, all symbols are located in a single
'compile unit', and the name of each symbol contains a reference to its
package, so 'dwz' is not able to deduplicate them. But still, some C
symbols included in the binary are deduplicated, which also alters the
structure of the DWARF sections, making delve unable to parse them
(crashing in the attempt).

While it would've been possible to simply ignore the C symbols, or
blindly loading all then into BinaryInfo members (packageVars,
Functions...), for correctness sake this change tries to do the right
thing, staging symbols into temporary partialUnit objects, moving them
to BinaryInfo when they are actually requested  by a 'imported unit'
tag.

Go seems to be generating multiple compilation units that have
the same file. I think this happens for functions that get inlined.
Without this patch, those inlined functions break the ability to set
a breakpoint at other lines in the file. I was able to load the same
binary in gdb and set a breakpoints throughout the file without issue.

```
➜ objdump --dwarf=decodedline automate-gateway | grep handler/users.go
.../handler/users.go:[++]
s/.../handler/users.go           20            0xb6dd88
.../handler/users.go:[++]
s/.../handler/users.go           20            0xb6e50f
.../handler/users.go:[++]
s/automate-gateway/handler/users.go           32            0xb66640
```

Inlined functions are still a little weird. setting a breakpoint on
a function that gets inlined picks the first occurence. That being
said, I think delve should still do something reasonable for the rest
of the lines in the file.

Go 1.10 added inlined calls to debug_info, this commit adds support
for DW_TAG_inlined_call to delve, both for stack traces (where
inlined calls will appear as normal stack frames) and to correct
the behavior of next, step and stepout.

The calls to Next and Frame of stackIterator continue to work
unchanged and only return real stack frames, after reading each line
appendInlinedCalls is called to unpacked all the inlined calls that
involve the current PC.

The fake stack frames produced by appendInlinedCalls are
distinguished from real stack frames by having the Inlined attribute
set to true. Also their Current and Call locations are treated
differently. The Call location will be changed to represent the
position inside the inlined call, while the Current location will
always reference the real stack frame. This is done because:

* next, step and stepout need to access the debug_info entry of
the real function they are stepping through
* we are already manipulating Call in different ways while Current
is just what we read from the call stack

The strategy remains mostly the same, we disassemble the function
and we set a breakpoint on each instruction corresponding to a
different file:line. The function in question will be the one
corresponding to the first real (i.e. non-inlined) stack frame.

* If the current function contains inlined calls, 'next' will not
set any breakpoints on instructions that belong to inlined calls. We
do not do this for 'step'.

* If we are inside an inlined call that makes other inlined
functions, 'next' will not set any breakpoints that belong to
inlined calls that are children of the current inlined call.

* If the current function is inlined the breakpoint on the return
address won't be set, because inlined frames don't have a return
address.

* The code we use for stepout doesn't work at all if we are inside
an inlined call, instead we call 'next' but instruct it to remove
all PCs belonging to the current inlined call.

updates vendored version of x86asm, adds a symbol lookup function to
pass to the disassembler.

This will show global symbol names in the disassembly like go tool
objdump does.