Does this issue reproduce with the latest release?

I didn't try.

You did use Go 1.12.7, which is the latest release.

/cc @cherrymui FYI per owners.

Can you give precise instructions for how to reproduce the problem? Thanks.

I compiled a rust archive with rustc and llvm optimization flag --codegen=lto. Trying to link that with go was causing the issue.

When I turned on optimizations --codegen=opt-level=3 then the problem went away. It was adding references to memcpy or memset that weren't used, I guess. I filed the issue because the error message is confusing.

If you need a minimal code example, I can put one together.

Edit: actually it came back after adding more logic. Not sure what is going on with missing memset, memcpy.

If you need a minimal code example, I can put one together.

Yes, please do.

Here's a reproduction: https://github.com/prestonvanloon/go-issue-33492

It's as minimal as I could make it.

Hmmm.... Calling into C directly from Go assembly is not a supported mechanism. Use cgo instead.

Allocating a large frame in assembly, rewinding the stack frame, then using that empty stack frame as a C stack is doubly not supported.

That said, the problem you're running into has nothing to do with that. I'm not sure why you're getting that error. It sounds like the Go linker is somehow trying to link the C code and getting confused by it. Probably not worth digging into it given the above, though. If you switch to using cgo and still run into this problem, feel free to reopen.

@FiloSottile

I need to put a flashier disclaimer on https://blog.filippo.io/rustgo. It was an experiment and a learning exercise, not something reproducible.

(Your issue though looks like you need to link a libc? Or maybe didn't succeed in making the Rust object no_std? If you want to continue down this path, I'd try forcing the external linker, and then debugging it as you would debug linking anything without the go build toolchain support. But again, this is not supported and it will eventually break and won't be fixed on our side.)

The main idea here was to avoid the cgo performance overhead, if it were possible. @FiloSottile's article looked promising, albeit a bit dated. I suspected I might hit a dead end here, but wanted to try it anyway.

I'll give the cgo approach a try. ~70ns overhead might be tolerable for my use case. Thanks for looking into it. I'll be sure to post a follow up here.

As a data point, I've hit this same issue in CI. If I find anything reproducable, I'll add it here. This is the error I got:

.dynsym: missing Go type information for global symbol: size 72
os/user(.text): relocation target malloc not defined for ABI0 (but is defined for ABI0)
os/user(.text): relocation target free not defined for ABI0 (but is defined for ABI0)
os/user(.text): relocation target getgrgid_r not defined for ABI0 (but is defined for ABI0)
os/user(.text): relocation target getgrnam_r not defined for ABI0 (but is defined for ABI0)
os/user(.text): relocation target getpwnam_r not defined for ABI0 (but is defined for ABI0)
os/user(.text): relocation target getpwuid_r not defined for ABI0 (but is defined for ABI0)
os/user(.text): relocation target realloc not defined for ABI0 (but is defined for ABI0)
os/user(.text): relocation target sysconf not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target stderr not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target fwrite not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target vfprintf not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target fputc not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target abort not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target pthread_mutex_lock not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target pthread_cond_wait not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target pthread_mutex_unlock not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target __stack_chk_fail not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target pthread_cond_broadcast not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target pthread_create not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target nanosleep not defined for ABI0 (but is defined for ABI0)
/usr/local/go/pkg/tool/linux_amd64/link: too many errors

What makes this especially weird is the following:

1. It only happens with go test, not when normally importing the package.
2. The erroring package does not use CGo directly (only through an intermediate package, which again works just fine with a regular build).

Also, this specifically happens with a CI Docker image.

@aykevl This issue is closed. If you do have a reproducible failure, please open a new issue with details. Thanks.