New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/cgo: pointer-passing rules may not be strong enough #22707

Open
bcmills opened this Issue Nov 14, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@bcmills
Member

bcmills commented Nov 14, 2017

In #12416, we (mostly @ianlancetaylor, I think) defined some restrictions on what C functions can do with Go pointers.

The current restrictions say, “The C code … must not store any Go pointers in Go memory, even temporarily.”

They do not prohibit the C code from storing non-Go pointers in Go memory, but I've been thinking about the pointer check a lot lately, and #20427 (comment) reminded me that C compilers can generate some pretty gnarly code.

In particular, C11 has a proper threading model, and a C11 compiler is allowed to assume that non-atomic writes do not race. It can rewrite them as, say, a store followed by an add, or a store of a spilled temporary followed by a load of that temporary and a store of the actual pointer. (Fortunately, I do not yet have an example of a C compiler actually generating such code.)

So now I'm not sure that the cgo pointer check is really strong enough after all: writes of non-Go pointers to Go pointer slots from C can, at least theoretically, race with the garbage collector tracing those slots, and cause it to observe invalid pointers.

To address that problem, I think we need to do one of:

  • Strengthen the existing sentence: “The C code … must not store any pointers in Go memory, even temporarily,” or
  • Add another clause: “The C code may store non-Go pointers in Go memory, but must ensure that each such store occurs atomically.”

(CC @dr2chase, @aclements, @RLH)

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 28, 2017

I think the rules are strong enough. I think that what you are discussing is the fact that optimizing C compilers may generate code that causes the rules to be broken even though the C code looks OK to the programmer.

I'm OK with adding a sentence warning about C compiler optimizations if you want to add one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment