This provides a better error message when the user tries to run dlv
debug on a directory that does not contain a main package, when `dlv
exec` is used with a source file.
Additionally the architecture of the executable is checked as suggested
by @alexbrainman in #443.
Fixes#509
* tests: update to cope with go1.7 SSA compiler
* de-vendored golang.org/x/debug/dwarf
We need our own tweaked version
* dwarf/debug/dwarf: always use the entry's name attribute
Using the name attribute leads to better type names as well as fixes
inconsistencies between 1.5, 1.6 and 1.7.
* proc: Updated loadInterface to work with go1.7
go1.7 changed the internal representation of types, removing the string
field from runtime._type.
Updated loadInterface to use the new str field.
Typedefs that resolve to slices are not recorded in DWARF as typedefs
but instead as structs in a way that there is no way to know they
are really slices using debug/dwarf.
Using golang.org/x/debug/dwarf instead this problem is solved and
as a bonus some types are printed with a nicer names: (struct string
→ string, struct []int → []int, etc)
Fixes#356 and #293
resume loops in continueOnce moved to a OS specific resume function,
this makes the problem easier to deal with and seems to be more
appropriate to a windows port given what transpired from discussion
of Pull Request #276
Breakpoints are skipped either because:
1. when multiple breakpoints are hit simultaneously only one is
processed
2. a thread hits a breakpoint while another thread is being
singlestepped over the breakpoint.
Additionally fixed a race condition between Continue and tracee
termination.
Only use software breakpoints for now. The reasoning is because it
complicates the code without justification, and is only supported on
Linux. Eventually, once watchpoints are properly implemented we will
revive some of this code. Also, if it is ever necessary to actually set
a hw breakpoint we can revive that code as well.
All future versions of this code will include support for OSX before
being merged back in.
This patch aims to improve how Delve tracks the current goroutine,
especially in very highly parallel programs. The main spirit of this
patch is to ensure that even in situations where the goroutine we care
about is not executing (common for len(g) > len(m)) we still end up back
on that goroutine as a result of executing the 'next' command.
We accomplish this by tracking our original goroutine id, and any time a
breakpoint is hit or a threads stops, we examine the stopped threads and
see if any are executing the goroutine we care about. If not, we set
'next' breakpoint for them again and continue them. This is done so that
one of those threads can eventually pick up the goroutine we care about
and begin executing it again.
We're not dealing with a debugged process having its own controlling
terminal at this point, so no need to make the new process a session
leader. Simply making the process a group leader will suffice for our
purposes at the moment.
Instead of fighting against the normal flow, just signal a SIGTRAP and
let the existing flow handle it, as long as we set the halt flag
correctly the system should halt.
For hardware breakpoints we have to set them on every thread. It could
be the case that another thread is running. Stop it first, set the
breakpoint, then continue it.
Previously either the terminal client or the debugger service would
either lock main goroutine to a thread or provide a locked goroutine to
run _all_ DebuggedProcess functions in. This is unnecessary because only
ptrace functions need to be run from the same thread that originated the
PT_ATTACH request.
Here we use a specific thread-locked goroutine to service any ptrace
request. That goroutine is also responsible for the initial spawning /
attaching of the process, since it must be responsible for the PT_ATTACH
request.
