Hi all, I have set up a github repository with the system call bindings for powerpc that we developed over the last months.
https://github.com/hcornelis/golang-sys Branch 'ppc-system-calls-v1'. I compared the system call bindings that are available from https://github.com/golang/go/issues/37443 and the system call bindings that we developed for running Docker on powerpc 32 bit based systems. The status and differences can be summarized as: 1. We mapped a few system call bindings to call the 64 bit variant of the system call (eg. fstat). This was necessary for our applications (Docker) to work. 2. Our generated system call binding set is larger. I assume because of differences in the used kernel header files and used options to generate the system call bindings. 3. I also implemented changes in the scripts that generate the structs of the bindings. For instance the epoll event struct had wrong alignment for some of its members in our first version of the bindings, so this was corrected by specific updates in the generator scripts (in unix/mkpost.go). There was also a problem with Statfs_t struct. 4. I am not an expert wrt cgo, but if I understand correctly, through the use of the cgo tool that is distributed with gccgo and knows ppc, we avoided small problems with cgo invocation. 5. I believe (all) the patches we did to the generator script 'mkall.go' are superseded by the upstream patches. Regards, Hugo On Fri, Oct 23, 2020 at 10:10 AM Hugo Cornelis <hugo.corne...@essensium.com> wrote: > > Hi Gerrit, > > Yes, that was the plan, but it looks like powerpc support was already > added to the sys/unix package last week. > > When we were working on this package we first had several subtle and > difficult to debug problems. As part of debugging, we developed unit tests > for validation of some of the system call bindings on powerpc using Qemu > and a physical device. > > I still plan to check the differences between our version of these > bindings and the upstream version and check if this could result in > problems (from quickly looking at the commits I can say that our bindings > should differ from the upstream version, but I have no idea about the > impact). > > I will get back to this next week and post here what I find. > > Hugo > > > On Thu, Oct 22, 2020 at 5:40 PM Gerrit Binnenmars < > gerritbinnenm...@gmail.com> wrote: > >> >> >> Hello Hugo, >> >> I did not succeed in getting crosstool-ng produce a go tool. Instead I >> adapted the source of the "normal" go tool and simply removed the check and >> added a fmt.Fprintf instead. It shows that even with go build -compiler >> gccgo the test is first called with the gc compiler and then with the gccgo >> compiler. So the test will always fail. I assume I still am doing something >> wrong but don't understand what. >> >> Meanwhile with the adapted go tool I can build the mender client >> application with the ppc gccgo compiler. Next problem is the missing >> support for ppc in golang.org/x/sys/unix. >> I also noticed that the community is interested in this: >> https://github.com/golang/go/issues/37443 >> Are you willing to share your unix package for ppc 32 bit architectures? >> >> With regards, Gerrit >> On Tuesday, October 20, 2020 at 9:52:17 AM UTC+2 hugo.c...@essensium.com >> wrote: >> >>> >>> >>> Hi Gerrit, >>> >>> If I understand correctly, I believe you try to cross-compile Go >>> applications to the PowerPC e500 architecture and as a first step you are >>> porting Go to this architecture. >>> >>> We recently ported Go applications such as Docker and its tools to >>> architectures not supported by upstream Go, but with an approach quite >>> different from yours (if I understood well). >>> >>> The procedure we follow, is: >>> >>> 1. Build the gccgo cross-toolchain with Buildroot: Buildroot currently >>> builds a toolchain by first building a gcc-initial, then proceeding to >>> build a gcc-final. We had to insert a new gcc compilation stage before >>> gcc-final can build the gccgo cross-compiler. This additional gcc >>> compilation stage makes go-tools available in the native environment that >>> are required for building the gccgo cross-compiler tools when gcc-final is >>> built. If I understand well this may be an important part of the solution >>> to your problem. >>> >>> 2. Patch the Buildroot environment to invoke gccgo as the compiler, >>> rather than gc, for compiling Go applications. We are planning to upstream >>> this and the previous step to Buildroot in the coming months. >>> >>> 3. Implement Go system call bindings: The sys package of the Go runtime >>> implements system call bindings as part of gccgo (so part of gcc-final), >>> the golang-sys/unix package is (can be) shipped in the folder >>> golang-sys/unix of the application you want to build (this is Docker and >>> tools in our case). The golang-sys package needs to be patched in each >>> application to produce correct system call bindings for your target >>> environment (so the PowerPC e500 in your case). Most of our development >>> time was spent in this last step (it is tricky). >>> >>> Using this procedure we have ported Docker and its dependencies and >>> tools to several ppc 32 bit architectures. >>> >>> I hope this helps. >>> >>> Hugo >>> >>> >>> >>> On Tue, Oct 20, 2020 at 6:20 AM gerritbinnenmars <gerritbi...@gmail.com> >>> wrote: >>> >>>> Hello Ian, >>>> Thanks for the quick reaction. It seems my request was not clear. >>>> What I am doing is the other way around: using gccgo to build the "go" >>>> cmd. >>>> So clone the "go" source from github and then go build -compiler gccgo >>>> ./cmd/go >>>> >>>> Gerrit >>>> >>>> -------- Oorspronkelijk bericht -------- >>>> Van: Ian Lance Taylor <ia...@golang.org> >>>> Datum: 20-10-20 04:25 (GMT+01:00) >>>> Aan: Gerrit Binnenmars <gerritbi...@gmail.com> >>>> Cc: golang-nuts <golan...@googlegroups.com> >>>> Onderwerp: Re: [go-nuts] gccgo problem compiling go from source >>>> >>>> On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars >>>> <gerritbi...@gmail.com> wrote: >>>> > >>>> > I used crosstool-ng successfully to build a go compiler for ppc e500. >>>> > Unfortunately go build does not support ppc therefore go needs to be >>>> > build from source using the amd64 gccgo compiler that I also build >>>> > with crosstool-ng. >>>> > >>>> > Compiling go from source fails: >>>> > Problem: undefined name stdpkg in internal/goroot/gccgo.go >>>> > >>>> > I included the output of my build script below. Any help or tips are >>>> welcome. >>>> > >>>> > With kind regards, >>>> > >>>> > Gerrit Binnenmars >>>> > >>>> > Info: >>>> > This is crosstool-NG version 1.24.0.191_364ed7a >>>> > GO111MODULE="" >>>> > GOARCH="amd64" >>>> > GOBIN="" >>>> > GOCACHE="/home/maintain/.cache/go-build" >>>> > GOENV="/home/maintain/.config/go/env" >>>> > GOEXE="" >>>> > GOFLAGS="" >>>> > GOHOSTARCH="amd64" >>>> > GOHOSTOS="linux" >>>> > GOINSECURE="" >>>> > GOMODCACHE="/home/maintain/gonew/pkg/mod" >>>> > GONOPROXY="" >>>> > GONOSUMDB="" >>>> > GOOS="linux" >>>> > GOPATH="/home/maintain/gonew" >>>> > GOPRIVATE="" >>>> > GOPROXY="https://proxy.golang.org,direct"; >>>> > >>>> GOROOT="/home/maintain/x-tools/x86_64-e500-linux-gnu/x86_64-e500-linux-gnu/sysroot/lib" >>>> > GOSUMDB="sum.golang.org" >>>> > GOTMPDIR="" >>>> > >>>> GOTOOLDIR="/home/maintain/x-tools/x86_64-e500-linux-gnu/x86_64-e500-linux-gnu/sysroot/lib/pkg/tool/linux_amd64" >>>> > GCCGO="/home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gccgo" >>>> > AR="ar" >>>> > CC="/home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gcc" >>>> > CXX="/home/maintain/x-tools/x86_64-e500-linux-gnu/bin/g++" >>>> > CGO_ENABLED="1" >>>> > GOMOD="" >>>> > >>>> CGO_CFLAGS="--with-sysroot=/home/maintain/x-tools/x86_64-e500-linux-gnu/x86_64-e500-linux-gnu/sysroot" >>>> > CGO_CPPFLAGS="" >>>> > CGO_CXXFLAGS="-g -O2" >>>> > CGO_FFLAGS="-g -O2" >>>> > CGO_LDFLAGS="-g -O2" >>>> > PKG_CONFIG="pkg-config" >>>> > GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 >>>> > -fdebug-prefix-map=/tmp/go-build355977706=/tmp/go-build >>>> > -gno-record-gcc-switches" >>>> > go version go1.15.2 linux/amd64 >>>> > gccgo (GCC) 10.2.0 >>>> > Copyright (C) 2020 Free Software Foundation, Inc. >>>> > This is free software; see the source for copying conditions. There >>>> is NO >>>> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>> PURPOSE. >>>> > >>>> > WORK=/tmp/go-build273889551 >>>> > mkdir -p $WORK/b100/ >>>> > cd $WORK >>>> > /home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gccgo >>>> > -fgo-importcfg=/dev/null -c -x c - -o /dev/null || true >>>> > cd /home/maintain/gonew/src/internal/goroot >>>> > /home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gccgo -c -g -m64 >>>> > -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches >>>> > -fgo-pkgpath=internal/goroot -o $WORK/b100/_go_.o -I >>>> > $WORK/b100/_importcfgroot_ ./gccgo.go >>>> > mkdir -p $WORK/b027/ >>>> > mkdir -p $WORK/b027/_importcfgroot_/cmd/go/internal >>>> > ln -s >>>> /home/maintain/.cache/go-build/ad/ade44815e7af8b7305b2db4099ec5b08aafcbd6e374a2c13d8e99c2986ca93c6-d >>>> > $WORK/b027/_importcfgroot_/cmd/go/internal/libauth.a >>>> > ln -s >>>> /home/maintain/.cache/go-build/d2/d26f05f163d86aecfadfbb952dfef9a314aa1c84c23fddd39bce127ccc85d101-d >>>> > $WORK/b027/_importcfgroot_/cmd/go/internal/libcfg.a >>>> > mkdir -p $WORK/b027/_importcfgroot_/cmd/internal >>>> > ln -s >>>> /home/maintain/.cache/go-build/2f/2f6811b0804c481edbfd9952d1aac22414f84ee1aec229218b03956bf3f9aa7a-d >>>> > $WORK/b027/_importcfgroot_/cmd/internal/libbrowser.a >>>> > cd /home/maintain/gonew/src/cmd/go/internal/web >>>> > /home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gccgo -c -g -m64 >>>> > -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches >>>> > -fgo-pkgpath=cmd/go/internal/web -o $WORK/b027/_go_.o -I >>>> > $WORK/b027/_importcfgroot_ ./api.go ./http.go ./url.go ./url_other.go >>>> > # internal/goroot >>>> > src/internal/goroot/gccgo.go:24:10: error: reference to undefined >>>> name 'stdpkg' >>>> > 24 | return stdpkg[path] >>>> > | ^ >>>> > # cmd/go/internal/web >>>> > src/cmd/go/internal/web/api.go:92:45: error: reference to undefined >>>> > field or method 'Redacted' >>>> > 92 | return nil, fmt.Errorf("reading %s: %v", u.Redacted(), err) >>>> >>>> It looks like you are using the "go" program to build the gccgo >>>> standard library. That doesn't work. The gccgo standard library must >>>> be built as part of GCC, using the usual configure/make commands used >>>> to build GCC itself. When configuring GCC, use --enable-languages=go. >>>> >>>> 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...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/5f8e657e.1c69fb81.3e6dc.0cf4%40mx.google.com >>>> <https://groups.google.com/d/msgid/golang-nuts/5f8e657e.1c69fb81.3e6dc.0cf4%40mx.google.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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/ee3608cf-b4e8-4d6e-b7bf-c2c3c0422feen%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/ee3608cf-b4e8-4d6e-b7bf-c2c3c0422feen%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAARrXCSYcnhY3W9SJ5u%3D2dwPo9tJ9-T5Mje3JyFVWxs0Zx0Vdw%40mail.gmail.com.
