Co-authored-by: NPolina Sokolova <polinasok@users.noreply.github.com>

Right now, if (*compositeMemory).WriteMemory needs to write a value to
a register that's smaller than the full size of the register (say, a
uint32 being passed as an argument), then (*AMD64Registers).SetReg can
later fail a sanity check that ensures the passed DwarfRegister is a
full size register.

Fix this by reading the old value of the register and overwriting just
the relevant parts with the new register. For the purposes of an
argument, it would probably be fine to just pad with zeroes, but merging
with the existing value is what gdb does.

Fixes #2698

Log points are special kinds of breakpoints that do not 'break' but instead log a message and then continue. This change implements basic log points that simply log the provided message, without any interpolation.

In order to resume execution after hitting a breakpoint, I added a new lock resumeMu and tracked the running state within the DAP server. resumeMu must be held in order to issue a debugger request that would start execution. This means it can be used to make sure that another goroutine does not resume execution while you are holding the lock.

Most of the synchronization logic is taken from PR #2530

Updates golang/vscode-go#123

This changes allow us to parse Go+BoringCrypto which formatted in <GoVersion>b<BoringCryptoVersion> so that we can surpress `Version of Go is too old for this version of Delve` error.

Fixes #2711

Release v1.7.2, update CHANGELOG.

* pkg/proc: update check for system goroutine

The finalizer goroutine can be either a system goroutine or a user goroutine. It is considered a user goroutine only when it calls back to user code. This change attempts to get closer to the implementation in the src/runtime/traceback.go by checking the value of fingRunning.

We could alternatively adopt the approximation done by src/cmd/trace/trace.go which only special cases "runtime.main", and always considers the finalizer to be a system goroutine.

The string variant is more powerful and can be passed
directly to "echo -e" / "printf" and friends.

Remove the mention of the integer variant from the default config. This
makes the option appear more consistent with other color options.
The user shouldn't care about the historic differences.

Commit 3d6bbbe9 made "config -list" print strings in quotes to avoid
the strings being interpreted as terminal escape codes.  This commit
does the same for "source-list-line-color", which is a raw interface.
This fixes "config -list" with a config like

	source-list-line-color: "\x1b[34m"

The "int" variant is already printed correctly, so just use the
default case for that.

errChan should not be closed otherwise the function that requests the
manual stop might find it closed.

These two were hard to read on default xterm or on Konsole's "White on
Black" theme. The non-bright colors still work on dark backgrounds.

See https://github.com/go-delve/delve/pull/2294#discussion_r691076091

If we cannot find debug information locally on the system, try and
invoke debuginfod-find in order to ask the linux distribution we're on
to find the debug information for us.

regabi is not supported on FreeBSD, the tests must act accordingly

This patch enables the eBPF tracer backend to parse the ID of the
Goroutine which hit the uprobe. This implementation is specific to AMD64
and will have to be generalized further in order to be used on other
architectures.

Adds a script that check automatically that the the assumptions that
pkg/proc makes about runtime are met by the actual runtime, using a
combination of parsing and magic comments.

Also emits a file describing all the struct fields, constants and
variables of the runtime that we use in pkg/proc.

Commit 8e91d3b0 added a number of configuration options to control the
colors of sytnax highlighting, unfortunately 'config -list' will print
all of those to stdout without quoting them, resulting in the color of
the last one being applied to all subsequent text.

Change 'config -list' to print strings in quotes so that we don't
accidentally send escape sequences to the terminal.

In order for DAP to support halting the program (either manually or on a breakpoint) performing some action and then resuming execution, there needs to be a way to stop the program without clearing the internal breakpoints. This is necessary for log points and stopping the program to set breakpoints.

The debugging UI makes it seem like a user should be able to set or clear a breakpoint at any time. Adding this ability to complete synchronous requests while the program is running is thus important to create a seamless user experience.

This change just adds a configuration to determine whether the target should clear the stepping breakpoints, and changes the server to use this new mode. Using the new mode means that the DAP server must determine when it expect the next to be canceled and do this manually.

* terminal,service: add way to see internal breakpoints

Now that Delve has internal breakpoints that survive for long periods
of time it will be useful to have an option to display them.

* proc,terminal,service: support stack watchpoints

Adds support for watchpoints on stack allocated variables.

When a stack variable is watched, in addition to the normal watchpoint
some support breakpoints are created:

- one breakpoint inside runtime.copystack, used to adjust the address
  of the watchpoint when the stack is resized
- one or more breakpoints used to detect when the stack variable goes
  out of scope, those are similar to the breakpoints set by StepOut.

Implements #279

* proc: move breakpoint condition evaluation out of backends

Moves breakpoint condition evaluation from the point where breakpoints
are set, inside ContinueOnce, to (*Target).Continue.

This accomplishes three things:

1. the breakpoint evaluation method needs not be exported anymore
2. breakpoint condition evaluation can be done with a full scope,
   containing a Target object, something that wasn't possible before
   because ContinueOnce doesn't have access to the Target object.
3. moves breakpoint condition evaluation out of the critical section
   where some of the threads of the target process might be still
   running.

* proc/native: handle process death during stop() on Windows

It is possible that the thread dies while we are inside the stop()
function. This results in an Access is denied error being returned by
SuspendThread being called on threads that no longer exist.

Delay the reporting the error from SuspendThread until the end of
stop() and only report it if the thread still exists at that point.

Fixes flakyness with TestIssue1101 that was exacerbated by moving
breakpoint condition evaluation outside of the backends.

This patch implements fuzzy searching for tab completions in the
terminal client. Under the hood it is using a trie data structure
(https://en.wikipedia.org/wiki/Trie) to perform very fast prefix / fuzzy
searches.

The install of gcc sometimes fails on our CI, it is not an error if the
tests for cgo can not run because there's no C compiler.

Fix ebpf build errors on Windows and update bininfo.Location API call.

Fixes #2636

Adds tests that make sure that when a next request
is interrupted by a breakpoint, the stepping breakpoints
are cleared.

* proc: Go 1.18 removes the _defer.siz field

As of Go 1.17, the _defer.siz field is always 0 because _defer no
longer stores defer call arguments at all. golang.org/cl/326062
removes it entirely for Go 1.18. Simply treat it as 0 if the field is
missing from the _defer type.

* proc: Go 1.18 changes _defer.fn from *funcval to func()

golang.org/cl/325918 changed the type of the _defer.fn field from
*funcval to func() for Go 1.18. This CL was later reverted because it
caused failures in Delve, but we would like to un-revert it. Handle
this change by inspecting the type of this field before decoding it.

Ignore existing breakpoints when using the continue command to continue
to a specific location such as `continue main.main`. The point of this
command is to continue to a specific location, so if there is already a
breakpoint set there there should be no error returned, just continue
until we hit the breakpoint already set in that location.

Before this change when you typed `help` at the Delve prompt you would
only see the following:

```
examinemem (alias: x)  Examine memory:
```

Now with this patch the output is more descriptive:

```
examinemem (alias: x)  Examine raw memory at the given address.
```

* pkg/proc: Prefer throw instead of fatalthrow

Currently there is a breakpoint set at runtime.fatalthrow to catch any
situation where the runtime crashes (e.g. deadlock).
When we do this, we go up a frame in order to parse the crash reason.
The problem is that there is no guarentee the "s" variable we attempt to
parse will still be considered "live".
Since runtime.fatalthrow is never called directly, set a breakpoint on
runtime.throw instead and prevent having
to search up a stack frame in order to
get the throw reason.

Fixes #2602

* service/dap: Fix TestFatalThrowBreakpoint

* Reenable TestFatalThrow DAP test

* service/dap: Don't skip test on < 1.17

* service/dap: Update test constraint for 1.16

* pkg/proc: Reinstate runtime.fatalthrow as switchstack exception

* cmd/dlv: dlv version --verbose

That prints out runtime/debug.BuildInfo read from the dlv binary.
Users can retrieve the same info using `go version -m <path_to_dlv>`
but I think it is convenient to have.

If dlv was built from cloned delve repo:

```
$ ./dlv version -v
Delve Debugger
Version: 1.7.0
Build: $Id: e353a65161e6ed74952b96bbb62ebfc56090832b $
Build Details: go1.16.5
 mod    github.com/go-delve/delve       (devel)
 dep    github.com/cosiner/argv v0.1.0  h1:BVDiEL32lwHukgJKP87btEPenzrrHUjajs/8yzaqcXg=
...
```

If dlv was built with `go install github.com/go-delve/delve@latest`
with go1.16+, or
`GO111MODULE=on go get github.com/go-delve/delve@latest`
from a clean main module:

```
$ ./dlv version -v
Delve Debugger
Version: 1.7.0
Build: $Id: e353a65161e6ed74952b96bbb62ebfc56090832b $
Build Details: go1.16.5
 mod    github.com/go-delve/delve       v1.7.0
 dep    github.com/cosiner/argv v0.1.0  h1:BVDiEL32lwHukgJKP87btEPenzrrHUjajs/8yzaqcXg=
...
```

* remove an accidentally added bogus test

* terminal: add prompt when breakpoint is hit during next/step/stepout

Adds a prompt asking the user what to do when a breakpoint is hit on a
different goroutine while next/step/stepout is being executed.
Gives the user the opportunity to cancel next/step/stepout, continue
once skipping the breakpoint or automatically skipping all other
concurrent breakpoints until next/step/stepout is finished.

Fixes #2317

StaticBase is the difference between the entry point declared in the
image file and the entry point as loaded in memory, since this
difference could be a negative number we have to use a signed
comparison when searching for a mapping.

Causes intermittent test failures on windows when resolving interface
types for position independent executables.

Fixes #2620

Conversion form a moduledata object into an image object was
implemented by looking for a function covering the start address of the
text section of the moduledata object, and then converting that into
its corresponding image.

Unfortunately this seems to not always work. In particular it does not
work on linux/386 with go1.17 (but it might also fail on other
combinations): the start address of the text section is, for whatever
reason, not part of any function.

As a fallback simply scan all images we know of and return the closest
one that has start address less than or equal to the start address of
the text section we are looking for.

Fixes TestPluginVariables on go1.17/linux/386.

Fixes #2611
Co-authored-by: Na <a@kra>

* terminal: improve 'on' command

Adds the ability to edit the list of commands executed after stopping
on a breakpoint, as well as converting a breakpoint into a tracepoint
and vice versa.

Prior to this it was possible to add commands to a breakpoint but
removing commands or changing a breakpoint into a tracepoint, or vice
versa, could only be done by removing and recreating the breakpoint.

Changes Breakpoint to allow multiple overlapping internal breakpoints
on the same instruction address.
This is done by changing the Breakpoint structure to contain a list of
"breaklets", each breaklet has a BreakpointKind and a condition
expression, independent of the other.
A breakpoint is considered active if any of its breaklets are active.
A breakpoint is removed when all its breaklets are removed.
We also change the terminology "internal breakpoint" to "stepping
breakpoint":

HasInternalBreakpoints -> HasSteppingBreakpoints
IsInternal -> IsStepping
etc...

The motivation for this change is implementing watchpoints on stack
variables.
Watching a stack variable requires also setting a special breakpoint to
find out when the variable goes out of scope. These breakpoints can not
be UserBreakpoints because only one user breakpoint is allowed on the
same instruction and they can not be internal breakpoints because they
should not be cleared when a next operation is completed (they should
be cleared when the variable watch is cleared).

Updates #279

This PR aims to add support for rr replay and core actions from the DAP layer. This basically encloses the following:
New launch modes: replay and core

The following modes are added:

    replay: Replays an rr trace, allowing backwards flows (reverse continue and stepback). Requires a traceDirPath property on launch.json pointing to a valid rr trace directory.
    Equivalent to dlv replay <tracedir> command.
    core: Replays a core dump file, showing its callstack and the file matching the callsite. Requires a coreFilePath property on launch.json pointing to a valid coredump file.
    Equivalent to dlv core <exe> <corefile> command.

Dependencies

To achieve this the following additional changes were made:

    Implement the onStepBackRequest and onReverseContinueRequest methods on service/dap
    Adapt onLaunchRequest with the requried validations and logic for these new modes
    Use CapabilitiesEvent responses to enable the StepBack controls on the supported scenarios (see dicussion here)
    Add the corresponding launch.json support on vs code: 

Support for replay and core modes golang/vscode-go#1268

* service/dap: add panic and throw text to stopped event

We can add more information to the stopped events on errors using
the `Text` field in the stopped event. We already use this to display
the runtime errors. Adding this information to the stopped reason will
also help to show the user additional info when a stopped event is not
associated with a particular goroutine.

* debugserver: fix typo in checking whether debugserver support unmask_signals

* gdbserver.go: fix issues in deepsource:go