Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/link: relocation target memcpy not defined for ABI0 (but is defined for ABI0) #33492
What version of Go are you using (
changed the title
link: relocation target memcpy not defined for ABI0 (but is defined for ABI0)
Aug 6, 2019
I compiled a rust archive with rustc and llvm optimization flag
When I turned on optimizations
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.
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.
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.