Hello Yuan Ting: I am trying to build Kubernetes with gollvm, and I am glad you have made some progress. Did you finish compiling Kubernetes with gollvm and generating IR? If it is true, could you show me some practical steps so I can compile the Kubernetes to LLVM IR files? Looking forward to your reply. Regards, Nanzi Yang
在2019年7月19日星期五 UTC+8 16:11:26<Yuan Ting> 写道： > Sorry to have troubled you again, I found that many famous Go projects > also import github.com/modern-go/reflect2 , such as kubernetes and moby. > According to the second paragraph in your explanation, these popular > projects will also failed in compilation. I think this may be a big > challenge for gccgo/gollvm's promotion. > > To solve this compiler-sensitive problem, the way I can come up with is > replacing all unsafe mechanisms as mentioned above in reflect2 to safe or > standard mechanisms (and may go against the purpose of reflect2). I'm not > familiar with runtime, but is it possible to support the same symbol in > gccgo/gollvm style? > > Best, > Ting > > On Thursday, July 18, 2019 at 10:55:39 PM UTC+8, Ian Lance Taylor wrote: > >> On Thu, Jul 18, 2019 at 6:50 AM Yuan Ting <yuan...@ict.ac.cn> wrote: >> > >> > Thank you for your fix. I have some curious about the difference >> between the main Go compiler and gollvm. I read gollvm's readme and know >> that the main difference comes from the efficiency of GC. Is the other >> difference causes the symbol undefined reference as you mentioned above? Or >> some bugs (or library version skew) that will be fixed in the future. >> >> The gc toolchain has a different assembler that does not use the same >> syntax as standard assembler for a platform >> (https://golang.org/cmd/asm). GoLLVM uses the standard assembler for >> whatever platform it is being used on. So Go packages that use >> assembler code, like golang.org/x/sys, have to use different code to >> support gc and GoLLVM. That is part of your problem. (That code does >> exist in current versions of golang.org/x/sys; the build above is >> showing an older version of the package; it's quite possible that >> current versions would work). >> >> The gc toolchain has a special approach for unifying type descriptors >> that uses a runtime-specific symbol runtime.typelinks. GoLLVM does >> not have that symbol. I don't know what github.com/modern-go/reflect2 >> is, but it seems to be using unsafe mechanisms to reach into the >> runtime to examine that symbol. That won't work with GoLLVM. The >> reflect package in general is closely tied to the compiler, so it's >> possible that whatever modern-go/reflect2 is, it will not work with >> GoLLVM. >> >> Ian >> > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a7d5df83-4149-4e5e-930d-a1acf2c74407n%40googlegroups.com.
