Go1.11 uses the is_stmt flag of .debug_line to communicate which
assembly instructions are good places for breakpoints, we should
respect this flag.
These changes were introduced by:
* https://go-review.googlesource.com/c/go/+/102435/
Additionally when setting next breakpoints ignore all PC addresses that
belong to the same line as the one currently under at the cursor. This
matches the behavior of gdb and avoids stopping multiple times at the
heading line of a for statement with go1.11.
Change: https://go-review.googlesource.com/c/go/+/110416 adds the
prologue_end flag to the .debug_line section to communicate the end of
the stack-split prologue. We should use it instead of pattern matching
the disassembly when available.
Fixes#550
type of interfaces
'c7cde8b'.
'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.
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.
If the last entry of the package path contains a '.' the corresponding
DIEs for its types will replace the '.' character with '%2e'. We must
do the same when resolving the package path of the concrete type of an
interface variable.
Fixes#1137
gosymtab and gopclntab only contain informations about go code, linked
C code isn't there, we should use debug_line instead to also cover C.
Updates #935
* string to []rune
* string to []byte
* []rune to string
* []byte to string
* any pointer to uintptr
The string, []rune, []byte conversion pairs aligns this to the go
language.
The pointer -> uintptr conversion pair is symmetric to the uintptr ->
pointer that we already have.
Also lets the user specify any size for byte array types instead of
just the ones already used by the program, this can be used to read
arbitrary memory.
Fixes#548, #867
Before go1.9 embedded struct fields had name == "" in runtime and ==
type name in DWARF. After go1.9 both runtime and DWARF use a simplified
version of the type as name.
Embedded structs are distinguished from normal fields by setting a flag
in the runtime.structfield, for runtime, and by adding a custom
attribute in DWARF.
Splits out type parsing and go-specific Type hierarchy from
x/debug/dwarf, replace x/debug/dwarf with debug/dwarf everywhere,
remove x/debug/dwarf from vendoring.
Variable lookup is slow because it requires a full scan of debug_info
to check for package variables, this doesn't matter much in interactive
use but can slow down evaluation of breakpoint conditions
significantly.
Providing benchmark proof for this is hard since this effect doesn't
show for small programs with small debug_info sections.
* proc: Refactor stackIterator to use memoryReadWriter and BinaryInfo
* proc: refactor EvalScope to use memoryReadWriter and BinaryInfo
* proc: refactor Disassemble to use memoryReadWriter and BinaryInfo
* 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
