Help with GOLLVM

[Danilo bestbug]

Hello,

I've create a docker images with ubuntu 20.10 with GOLLVM, I'm using at the moment a simple test repository, I was able to create the ll file with the following command:

go build -gccgoflags -static-libgo -x -work 1> transcript.txt 2>&1

WORK=$(egrep -m 1 '(WORK=|llvm-goc -c)' transcript.txt | awk '{ print substr ($0, 6 ) }')

/gollvm/install/bin/llvm-goc -c -O2 -g -m64 -fdebug-prefix-map=$WORK=/tmp/go-build \

-gno-record-gcc-switches -fgo-pkgpath=$PWD \

-fgo-relative-import-path=$PWD -o $WORK/b001/_go_.o \

-I $WORK/b001/_importcfgroot_ -o $LLFILE -S -emit-llvm $MAINFILE

But when I try to convert to binary via clang the file I've some error:

clang helloworld.ll -o helloworldLLVM
warning: overriding the module target triple with x86_64-pc-linux-gnu [-Woverride-module]
1 warning generated.
/usr/bin/ld: /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
/usr/bin/ld: /tmp/helloworld-bcb8cc.o: in function `_..z2fopt..z2fvmsdk..z2fhelloworld.describe':
/opt/vmsdk/helloworld/./describe.go:6: undefined reference to `runtime.newobject'
/usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference to `runtime.writeBarrier'
/usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference to `fmt.Printf'
/usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference to `runtime.typedmemmove'
/usr/bin/ld: /tmp/helloworld-bcb8cc.o:(.rodata.string..d[string..d]+0x18): undefined reference to `runtime.strequal..f'
/usr/bin/ld: /tmp/helloworld-bcb8cc.o:(.rodata.type...1string[type...1string]+0x18): undefined reference to `runtime.memequal64..f'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I'm this is the first time I use this buildchain and I don't understand what I'm doing wrong. Can someone help me?

Those are the commit I've used for build gollvm, if needed

llvm-project: 43ff75f2c3feef64f9d73328230d34dac8832a91

llvm-project/llvm/tools/gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc

llvm-project/llvm/tools/gollvm/gofrontend: be0d2cc2df9f98d967c242594838f86362dae2e7

llvm-project/llvm/tools/gollvm/libgo/libffi: 737d4faa00d681b4c758057f67e1a02d813d01c2

llvm-project/llvm/tools/gollvm/libgo/libbacktrace: 5a99ff7fed66b8ea8f09c9805c138524a7035ece

Thanks in advance!

[Than McIntosh]

Greetings,

The code that Go compilers emit is closely tied to the Go runtime-- any compiled Go code (including *.ll files) will have references to symbols that it needs from the runtime. When you try to convert your LLVM-produced bitcode into a binary via

clang helloworld.ll -o helloworldLLVM

you're effectively not including definitions of any of those key runtime routines (for example, "runtime.newobject", which is one of the functions that supports memory allocation).

It would be similar to what might happen if you took a C++ "hi mom" program, compiled it down to an object file using "clang++", then tried to link the resulting object into a binary using "gcc".

Hope this helps--

Than

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d503d8bf-e904-42be-9955-6813d4f8c29fn%40googlegroups.com.

[Danilo bestbug]

Hello,

Thanks for the answer. I've still some question then. The whole point of my poc was to be able to get the LLVMIR of GO then put it into an iOS app with bitcode enable. What are you saying is that it is not possible to achieve this? Or it's possible but I've to add the missing symbols? If is the second thing do you have any idea how to do this?

Thanks!

[Than McIntosh]

Hi,

>>The whole point of my poc was to be able to get the LLVMIR of GO then put it into an iOS app with bitcode enable. What are you saying is that it is not possible to achieve this?

It's definitely outside the normal/expected use of gollvm, but it seems at least possible to do this.  

The key thing is that for a Go program to run, it needs copies of all its dependent packages. That means that those packages need to be compiled down to bitcode as well, and then the whole collection handed off to whatever is going to be executing the bitcode.

To list your transitive dependencies, you can do something like

  $ go list -json hello2.go

and then look at the "Deps" section.

I think the last time this was attempted, some hacks were required in the runtime (see https://go-review.googlesource.com/c/gofrontend/+/140917), so you might need to dust off that CL and get it working again. 

Thanks, Than