diff options
author | Ian Lance Taylor <ian@gcc.gnu.org> | 2017-06-23 20:19:40 +0000 |
---|---|---|
committer | Ian Lance Taylor <ian@gcc.gnu.org> | 2017-06-23 20:19:40 +0000 |
commit | f1857c636967baea1e29af2e3ed72de7e5be3895 (patch) | |
tree | 19a34329dba9299efacbc2aaa92dce5f1108fe94 /gcc/go | |
parent | 0f0d0eaae5e0b07dd5a08be93ba0009b1146cf76 (diff) | |
download | gcc-f1857c636967baea1e29af2e3ed72de7e5be3895.zip gcc-f1857c636967baea1e29af2e3ed72de7e5be3895.tar.gz gcc-f1857c636967baea1e29af2e3ed72de7e5be3895.tar.bz2 |
runtime: complete defer handling in CgocallBackDone
When C code calls a Go function, it actually calls a function
generated by cgo. That function is written in Go, and, among other
things, it calls the real Go function like this:
CgocallBack()
defer CgocallBackDone()
RealGoFunction()
The deferred CgocallBackDone function enters syscall mode as we return
to C. Typically the C function will then eventually return to Go.
However, in the case where the C function is running on a thread
created in C, it will not return to Go. For that case we will have
allocated an m struct, with an associated g struct, for the duration
of the Go code, and when the Go is complete we will return the m and g
to a free list.
That all works, but we are running in a deferred function, which means
that we have been invoked by deferreturn, and deferreturn expects to
do a bit of cleanup to record that the defer has been completed. Doing
that cleanup while using an m and g that have already been returned to
the free list is clearly a bad idea. It was kind of working because
deferreturn was holding the g pointer in a local variable, but there
were races with some other thread picking up and using the newly freed g.
It was also kind of working because of a special check in freedefer;
that check is no longer necessary.
This patch changes the special case of releasing the m and g to do the
defer cleanup in CgocallBackDone itself.
This patch also checks for the special case of a panic through
CgocallBackDone. In that special case, we don't want to release the m
and g. Since we are returning to C code that was not called by Go
code, we know that the panic is not going to be caught and we are
going to exit the program. So for that special case we keep the m and
g structs so that the rest of the panic code can use them.
Reviewed-on: https://go-review.googlesource.com/46530
From-SVN: r249611
Diffstat (limited to 'gcc/go')
-rw-r--r-- | gcc/go/gofrontend/MERGE | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE index e2d91ad..416a587 100644 --- a/gcc/go/gofrontend/MERGE +++ b/gcc/go/gofrontend/MERGE @@ -1,4 +1,4 @@ -fc0cfdff94ca1099421900f43837ca5a70189cd6 +0a20181d00d43a423c55f4e772b759fba0619478 The first line of this file holds the git revision number of the last merge done from the gofrontend repository. |