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/compile: document emitptrargsmap onebitwalktype1 calls #24648

Open
josharian opened this Issue Apr 2, 2018 · 3 comments

Comments

Projects
None yet
4 participants
@josharian
Contributor

josharian commented Apr 2, 2018

Perhaps I'm missing something, but this sequence of calls in emitptrargsmap looks suspect:

	if fn.IsMethod() {
		onebitwalktype1(fn.Type.Recvs(), 0, bv)
	}
	if fn.Type.NumParams() > 0 {
		onebitwalktype1(fn.Type.Params(), 0, bv)
	}

If I'm reading it correctly, this will overwrite the Recvs bitmap with the Params bitmap.

Also, after emitting that bitmap, we do:

	if fn.Type.NumResults() > 0 {
		onebitwalktype1(fn.Type.Results(), 0, bv)
		off = dbvec(lsym, off, bv)
	}

But we don't clear bv first, so any set bits from recvs/params will still be set.

emitptrargsmap is only called from assembly functions, which are unlikely to have methods and which are often nosplit, which is possibly why this hasn't caused visible problems yet (?).

cc @mdempsky -- does this code look right to you, and if so, what am I missing?

@josharian josharian added this to the Go1.11 milestone Apr 2, 2018

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Jun 30, 2018

@mdempsky

This comment has been minimized.

Member

mdempsky commented Jul 2, 2018

I think that code is fine.

We create that bitmap to implement GO_ARGS and GO_RESULTS_INITIALIZED from runtime/funcdata.h. The first bitmap (recvs+params) is to represent at function entry (when only params are live), and the second bitmap (recvs+params+results) is to represent once the results have been initialized within the assembly code.

It's okay to call them all like that because function parameter fields have their Xoffsets set according to their frame offset.

@mdempsky mdempsky closed this Jul 2, 2018

@josharian

This comment has been minimized.

Contributor

josharian commented Jul 16, 2018

Thanks, @mdempsky. We should add a comment in the code; re-opening this for a doc fix in 1.12.

@josharian josharian reopened this Jul 16, 2018

@josharian josharian changed the title from cmd/compile: emitptrargsmap looks buggy to cmd/compile: document emitptrargsmap onebitwalktype1 calls Jul 16, 2018

@josharian josharian modified the milestones: Go1.11, Go1.12 Jul 16, 2018

@josharian josharian added the NeedsFix label Jul 16, 2018

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