runtime: avoid write barriers with traceback info
authorIan Lance Taylor <ian@gcc.gnu.org>
Thu, 13 Sep 2018 17:30:00 +0000 (17:30 +0000)
committerIan Lance Taylor <ian@gcc.gnu.org>
Thu, 13 Sep 2018 17:30:00 +0000 (17:30 +0000)
commitf0d89c7759e7be18895868e0c4e7f9e120f7890f
treeffb6a90f3e684836545e8c93e21e30588428ca11
parent5f54d5fee46b8f1a0a78a8fbeb03e3ddfc8c9346
runtime: avoid write barriers with traceback info

    Unlike the gc runtime, libgo stores traceback information in location
    structs, which contain strings.  Therefore, copying location structs
    around appears to require write barriers, although in fact write
    barriers are never important because the strings are never allocated
    in Go memory.  They come from libbacktrace.

    Some of the generated write barriers come at times when write barriers
    are not permitted.  For example, exitsyscall, marked
    nowritebarrierrec, calls exitsyscallfast which calls traceGoSysExit
    which calls traceEvent which calls traceStackID which calls
    trace.stackTab.put which copies location values into memory allocated
    by tab.newStack.  This write barrier can be invoked when there is no
    p, causing a crash.

    This change fixes the problem by ensuring that location values are
    copied around in the tracing code with no write barriers.

    This was found by fixing the compiler to fully implement
    //go:nowritebarrierrec; CL to follow.

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

From-SVN: r264282
gcc/go/gofrontend/MERGE
libgo/go/runtime/proc.go
libgo/go/runtime/runtime2.go
libgo/go/runtime/trace.go
libgo/go/runtime/traceback_gccgo.go
libgo/runtime/proc.c