Re: [ptxdist] Go in ptxdist

[Clemens Gruber <clemens.gruber@pqgruber.com>]

On Wed, Oct 05, 2016 at 03:13:27PM +0200, Michael Olbrich wrote:
> On Tue, Oct 04, 2016 at 05:23:25PM +0200, Clemens Gruber wrote:
> > Hi,
> > 
> > I'd like to start a discussion about implementing support for Go
> > language projects in ptxdist. https://golang.org
> > 
> > The nice thing about the recent Go versions is that cross compilation is
> > possible without recompiling Go for the target architecture.
> > You can use the Go version from your host and cross compile to the
> > supported target architectures and operating system.
> > Go binaries are statically compiled, so we would only need Go on the
> > host system.
> > 
> > To cross-compile an ARMv7 binary, you just call:
> > env GOOS=linux GOARCH=arm GOARM=7 go build helloworld.go
> > Tested with Go 1.7.1 on ArchLinux and cross-compiled binary is running
> > successfully on an i.MX6Q.
> > If you are wondering about my use case:
> > I am implementing a Webapp backend with Revel (github.com/revel/revel)
> > for the admin interface to our embedded product and Go is a fine
> > language for writing server software.
> > 
> > --
> > 
> > What are your thoughts about this?
> 
> In PTXdist things should be reproducible. So relying on a compiler for
> target code in the host system is not a good idea.
> I'm not familiar with Go. Would creating a 'host-go' package be feasible?

Yes. I just meant it does not need a separate cross stage and toolchain.
A 'host-go' package to be consistent in respect to the Go versions used
to build would be a good idea!

> 
> > --
> > 
> > Maybe:
> > Having a new FOO_CONF_TOOL value "go" similar to "python3" and adding
> > additional case statements to scripts/lib/ptxd_make_world_*.sh and
> > building the Go files there, either via go build or using go install.
> > 
> > We probably need a static mapping from supported toolchain ABIs to
> > GOARCH (and GOARM) values:
> > aarch64-v8a-linux-gnu       -> GOARCH=arm64
> > arm-1136jfs-linux-gnueabi   -> GOARCH=arm GOARM=5
> 
> Are you sure that this is correct? The compiler will produce ARMv6 code.

Yes, I think so. Go supports softfloat only for ARMv5, that's why I
would set GOARM to 5 for all softfloat systems.

I got the information from https://github.com/golang/go/wiki/GoArm

Processors implementing ARMv6/7 architecture can execute ARM code for
ARMv5, right? (I think Thumb/Thumb2 would be more problematic, but afaik
Go does not generate any Thumb code)

> 
> > arm-1136jfs-linux-gnueabihf -> GOARCH=arm GOARM=6
> > arm-cortexa8-linux-gnueabi  -> GOARCH=arm GOARM=5
> 
> same here.
> 
> > arm-cortexa8-linux-gnueabihf-> GOARCH=arm GOARM=7
> > arm-v5te-linux-gnueabi      -> GOARCH=arm GOARM=5
> > arm-v7a-linux-gnueabi       -> GOARCH=arm GOARM=5
> 
> and here.
> 
> > arm-v7a-linux-gnueabihf     -> GOARCH=arm GOARM=7
> 
> I'd prefer it if we cleaned up the arm architecture stuff in
> architecture.in to make this explicit.

Do you mean adding config options for V5 and V7?
And then deducing the correct GOARCH and GOARM from the ptxconfig
settings instead of the used toolchain's ABI?

> 
> > i586-unknown-linux-gnu      -> GOARCH=386
> > i686-atom-linux-gnu         -> GOARCH=386
> > x86_64-unknown-linux-gnu    -> GOARCH=amd64
> > 
> > Go supports >=ARMv6 builds with hardfloat only, so I'd fall back to
> > building ARMv5 binaries for ARMv6/7 softfloat configurations.
> 
> Are you sure this means it cannot create armv6/7 softfloat?

They write: "ARM on Linux. You must run an EABI kernel. These are
generally known as armel for softfloat (compatible with ARMv5) or armhf
for hardware floating point (ARMv6 and above)."

If you set GOARM to 6 or 7 it always creates hardfloat code. So I think,
setting it to anything else than 5 would lead to a crash on all
architectures without a VFP unit?

Clemens

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de