Gollvm: Some existing defects

[JX-Zhang98]

What version of Go are you using (go version)?

$ go version
go version go1.16.3 gollvm LLVM 13.0.0git linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/lyf//workspace/gowork/bin"
GOCACHE="/home/lyf/.cache/go-build"
GOENV="/home/lyf/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/lyf/workspace/gowork/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/lyf//workspace/gowork"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/home/lyf/.local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/lyf/.local/gollvm/tools"
GOVCS=""
GOVERSION="go1.16.3 gollvm LLVM 13.0.0git"
GCCGO="/home/lyf/.local/gollvm/bin/llvm-goc"
AR="ar"
CC="/home/lyf/.local/llvmtools/bin/clang"
CXX="/home/lyf/.local/llvmtools/bin/clang++"
CGO_ENABLED="1"
GOMOD="/home/lyf/workspace/gowork/src/hwprojects/beego/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3381461740=/tmp/go-build -gno-record-gcc-switches -funwind-tables"

What did you do?

I've tested gollvm on a large number of projects and that there are still some bugs in it.
Its robustness makes me uneasy

What did you expect to see?

I want to know if these bugs or defects are likely to be solved in a later version,
or if there is any way to overcome them

What did you see instead?

These bugs and defects include:

1. go://linkname
   Access to private functions in the standard library through linkname is not allowed in gollvm, but this operation is not uncommon.
   As discussed in golang-nuts
   In addition, go:linkname' is only supported for functions
2. asm
   Many projects rely on assembly functions implemented using plan9 syntax, which is not suppored by gollvm
   This causes gollvm to be unavailable on these projects.
   Maybe, compile the plan9 asm to an ELF object and add a bridge for it is possible?
3. error caused by -fsplit-stack
   When compiling some projects using gollvm with a clang C compiler，the arg -fsplit-stack is add automatically, which leads to a backend err in llvm
   issue 41399 mentioned it
4. go://embed
   It seems that gollvm has not yet been very good support for this new feature
   Details about it are here: issue 45880

---

I'd like to know if the fix of these bugs or defects is in your plan, and whether it is possible to fix them in subsequent versions
Thank you

[thanm]

Hi,

As you are probably aware, we don't use the issue tracker for asking questions -- better to pose your questions on a mailing list or some other forum.

Access to private functions in the standard library through linkname is not allowed in gollvm

Gollvm supports //go:linkname, just in a different way from the main Go toolchain, since its runtime and standard library are implemented somewhat differently.

In terms of using //go:linkname for non-functions, the limitations in gollvm relate to the use of the system linker. Gollvm has to emit ELF object files (in comparison with the main Go toolchain, which uses a custom object file, and which uses its own linker); because of this it seems unlikely that gollvm will support this use case any time soon.

I'll add (once again) that using //go:linkname to "reach into" the runtime/stdlib and access unexported functions is highly non-portable and not covered by any Go compatibility guarantee. Such programs can be broken at any time by a new Go release.

Many projects rely on assembly functions implemented using plan9 syntax, which is not suppored by gollvm

Regarding the assembly syntax, there is no plan to add a "plan 9 to ELF syntax" translator, this would be a major undertaking. I would recommend that when you encounter build problems of this nature that you file bugs with the project hostig the assembly, requesting that they introduce a gccgo/gollvm build tag to pick up an alternate Go version of the function in question.

...

Relating to the other bugs, yes, hopefully someone (myself or another) will try to work on these as time permits. Gollvm is an open source project; things get done because developers contribute their time to help with it.

Thanks.

[ianlancetaylor]

Note that simply converting Plan 9 asm to ELF is not enough, as the calling conventions are different. Even if wrote a translator, the resulting code would not work. So we would also have to generate some sort of ABI translation wrappers.

[JX-Zhang98]

Thank you for your response and reminder. We've talked about the problem of asm on golang-nuts several times：)
If necessary in my subsequent work, I will remember to add a bridge for ELF from ASM to adapt to different calling conventions.
Thanks~