runtime: scan caller-saved registers for non-split-stack

runtime: scan caller-saved registers for non-split-stack

    While testing a patch on Solaris, which does not support split-stack, I
    ran across a bug in the handling of caller-saved registers for the
    garbage collector.  For non-split-stack systems, runtime_mcall is
    responsible for saving all caller-saved registers on the stack so that
    the GC stack scan will see them.  It does this by calling
    __builtin_unwind_init and setting the g's gcnextsp field to point to the
    current stack.  The garbage collector then scans the stack from gcnextsp
    to the top of stack.

    Unfortunately, the code was setting gcnextsp to point to runtime_mcall's
    argument, which meant that even though runtime_mcall was careful to
    store all caller-saved registers on the stack, the GC never saw them.
    This is, of course, only a problem if a value lives only in a
    caller-saved register, and not anywhere else on the stack or heap.  And
    it is only a problem if that caller-saved register manages to make it
    all the way down to runtime_mcall without being saved by any function on
    the way.  This is moderately unlikely but it turns out that the recent
    changes to keep values on the stack when compiling the runtime package
    caused it to happen for the local variable `s` in `notifyListWait` in
    runtime/sema.go.  That function calls goparkunlock which is simple
    enough to not require all registers, and itself calls runtime_mcall.  So
    it was possible for `s` to be released by the GC before the goroutine
    returned from goparkunlock, which eventually caused a dangling pointer
    to be passed to releaseSudog.

    This is not a problem on split-stack systems, which use
    __splitstack_get_context, which saves a stack pointer low enough on the
    stack to scan the registers saved by runtime_mcall.

    Reviewed-on: https://go-review.googlesource.com/31323

From-SVN: r241304