Stack barriers were removed in Go 1.9, and thus code that
expected various stack-barrier-related symbols to exist
does not find them. Check for their absence and do not
crash when they are missing. Disable stack-barrier-handling
test for 1.9 and beyond.
Fixes#754.
On Windows we can sometimes encounter threads stopped in locations for
which we do not have entries in debug_frame.
These cases seem to be due to calls to Windows API in the go runtime,
we can still produce a (partial) stack trace in this circumstance by
following frame pointers (starting with BP).
We still prefer debug_frame entries when available since go functions
do not have frame pointers before go1.8.
The PC we have is relative to the first instruction after the CALL
instruction currently being executed.
Anyone watching a disassembly will understand what's happening if we
report the return PC, but reporting the first PC of the current line is
useless and confusing.
