Ok, for normal assembly functions, the obj package will insert a FUNCDATA which refers to the args_stackmap generated by the compiler from the Go declaration.
https://go.googlesource.com/go/+/master/src/cmd/internal/obj/plist.go#78
But this is only done for functions whose name starts with ""., which means, defined in the same package.

Maybe we can make the obj package also insert FUNCDATA for functions not defined in the same package as the declaration? Or the assembly writer is expected to write a GO_ARGS pseudo-instruction (https://go.googlesource.com/go/+/master/src/runtime/funcdata.h#34) for this kind of functions?

CC @aclements @randall77

I'd rather avoid the GO_ARGS solution. We can certainly do that for internal/bytealg, but this problem would occur for anyone writing an assembly routine that is exported. I don't want them writing a GO_ARGS declaration when we have all the information we need to construct it for them.

What happens if we just remove the "". restriction? Does everything still work? How much extra linker work is it? Extra binary size?

Maybe we could restrict to functions which have a declaration but no body. I'm not sure whether we have that bit in the data exported from a package, though.

What happens if we just remove the "". restriction? Does everything still work?

This doesn't work, since not all assembly functions have Go declarations. For them, it will result in undefined relocation targets at link time. I tried restricting to only functions whose name has a ".", but still some functions don't have Go declarations. Maybe we can establish a convention that if a function doesn't have Go declaration (therefore cannot be called from Go), it should not have "." (written as "·" in assembly source code) in its name? We could fix up the exceptions in std, but not sure what to do with code outside our repo.

Can we restrict to exported functions? I think it would be reasonable to require that exported assembly functions have Go declarations. In fact, I don't think it would work otherwise (unless assembly was calling assembly?).

I'd rather avoid the GO_ARGS solution. We can certainly do that for internal/bytealg, but this problem would occur for anyone writing an assembly routine that is exported.

I may be misunderstanding, but doesn't this also require that the assembly routine be implemented in a different package than its Go declaration? I'm okay with saying that end users don't get to do that.

@aclements Yes, I guess that's true.
In any case, I have a patch that restricts to exported functions, and it seems to work. I'll mail it in a sec.

Change https://golang.org/cl/122519 mentions this issue: cmd/compile: use Go declaration to make GO_ARGS for assembly functions.

My patch didn't quite work, due to shared libraries.
When building runtime as a shared library, that shared library actually includes the implementations of bytes.IndexByte, for example. That implementation now references bytes.IndexByte.args_stackmap as its args pointer map funcdata. But that symbol doesn't exist when compiling runtime, and won't exist if you never use the bytes package.

Adding something like:

FUNCDATA $0, ·IndexByte·args_stackmap(SB)

to the bytes.IndexByte assembly fixes things. Of course, that's probably the original GO_ARGS fix Cherry suggested.
I guess that's good enough to fix this bug, I'll whip up a CL.
There's the remaining question of whether my CL 122519 should be submitted. I think it might still be a good fix for people deferring exported assembly functions which don't have package "". (Presumably people use pkg·Func as well as ·Func to declare their assembly functions.)

Change https://golang.org/cl/122676 mentions this issue: internal/bytealg: specify argmaps for exported functions