[ptxdist] Go in ptxdist

[ptxdist] Go in ptxdist

[Clemens Gruber]

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?

--

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
arm-1136jfs-linux-gnueabihf -> GOARCH=arm GOARM=6
arm-cortexa8-linux-gnueabi  -> GOARCH=arm GOARM=5
arm-cortexa8-linux-gnueabihf-> GOARCH=arm GOARM=7
arm-v5te-linux-gnueabi      -> GOARCH=arm GOARM=5
arm-v7a-linux-gnueabi       -> GOARCH=arm GOARM=5
arm-v7a-linux-gnueabihf     -> GOARCH=arm GOARM=7
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.

The mininum size of the generated binaries is still rather large, but
this will improve in Go 1.8: https://blog.golang.org/go1.7-binary-size
(At the moment, my hello world example is 927KB if stripped, as it
includes the statically linked runtime)
I probably would not use it for small little tools running only for
short time periods, but for long-running server software, it's fine.

Regards,
Clemens

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Michael Olbrich]

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?

> --
> 
> 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.

> 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.

> 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?

> The mininum size of the generated binaries is still rather large, but
> this will improve in Go 1.8: https://blog.golang.org/go1.7-binary-size
> (At the moment, my hello world example is 927KB if stripped, as it
> includes the statically linked runtime)
> I probably would not use it for small little tools running only for
> short time periods, but for long-running server software, it's fine.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Clemens Gruber]

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

Re: [ptxdist] Go in ptxdist

[Michael Olbrich]

Hi,

On Wed, Oct 05, 2016 at 05:55:10PM +0200, Clemens Gruber wrote:
> On Wed, Oct 05, 2016 at 03:13:27PM +0200, Michael Olbrich wrote:
> > 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?

We should probably have options for v5/v6/v7 and for armel vs. armhf. And
checks, that the toolchain does the right thing. And then use these options
to configure Go correctly.

Side note: the toolchain check is non-trivial because there are gcc
versions that produce armhf code but do not define any macros that we could
use to identify this. I need to think about how to check this correctly.

This would be also interesting for other use-cases: I've worked with binary
software (OpenGL drives etc.) that couldn't compile. In that case, this
would be great to make sure things are consistent.
Mixing armel and armhf library does _not_ fail when starting the
application, but breaks later because the function argument are not
interpreted correctly...

> > > 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?

This description is a bit vague. In general, whether armel or armhf is used
does not depend on the ARM architecture, so armel on ARMv7 (and using
floating point instructions!) is perfectly valid.
We need to investigate if armhf is just the default for ARMv6/7 or if that
can be configured.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Clemens Gruber]

Hi,

On Wed, Oct 05, 2016 at 06:31:17PM +0200, Michael Olbrich wrote:
> This description is a bit vague. In general, whether armel or armhf is used
> does not depend on the ARM architecture, so armel on ARMv7 (and using
> floating point instructions!) is perfectly valid.
> We need to investigate if armhf is just the default for ARMv6/7 or if that
> can be configured.

Yes, I found more information on this topic:

$GOARM (for arm only; default is auto-detected if building on the target
processor, 6 if not)
This sets the ARM floating point co-processor architecture version the
run-time should target. If you are compiling on the target system, its
value will be auto-detected.
- GOARM=5: use software floating point; when CPU doesn't have VFP
  co-processor
- GOARM=6: use VFPv1 only; default if cross compiling; usually ARM11 or
better cores (VFPv2 or better is also supported)
- GOARM=7: use VFPv3; usually Cortex-A cores

See: https://golang.org/doc/install/source#environment

So we have to use 5 for all softfloat architectures, no matter if they
are ARMv5, v6 or v7 based.
So only for ARMv6 and ARMv7 with hardfloat we would use a GOARM value of
6 and 7 respectively.

They also seem to use ARMv7 Data Memory Barrier instructions if GOARM==7
https://github.com/golang/go/blob/master/src/runtime/asm_arm.s#L716

--

Something else I forgot to mention:
Since a few releases, Go is implemented in Go (and a little bit of asm)
and no longer in C, which means, to build Go, you need to bootstrap it
with a binary Go for your host architecture.
They do release official Linux binaries for amd64, 386 and armv6l (with
the l standing for little endian I assume)
Do you think there are PTXdist users out there who are running it on
non-amd64 hosts? What host platforms do we have to support?

Maybe we could also bootstrap it with gccgo (but then we would need a
toolchain containing a GCC built with --enable-languages=c,c++,go).

Clemens

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Michael Olbrich]

Hi,

On Wed, Oct 05, 2016 at 10:42:41PM +0200, Clemens Gruber wrote:
> On Wed, Oct 05, 2016 at 06:31:17PM +0200, Michael Olbrich wrote:
> > This description is a bit vague. In general, whether armel or armhf is used
> > does not depend on the ARM architecture, so armel on ARMv7 (and using
> > floating point instructions!) is perfectly valid.
> > We need to investigate if armhf is just the default for ARMv6/7 or if that
> > can be configured.
> 
> Yes, I found more information on this topic:
> 
> $GOARM (for arm only; default is auto-detected if building on the target
> processor, 6 if not)
> This sets the ARM floating point co-processor architecture version the
> run-time should target. If you are compiling on the target system, its
> value will be auto-detected.
> - GOARM=5: use software floating point; when CPU doesn't have VFP
>   co-processor
> - GOARM=6: use VFPv1 only; default if cross compiling; usually ARM11 or
> better cores (VFPv2 or better is also supported)
> - GOARM=7: use VFPv3; usually Cortex-A cores
> 
> See: https://golang.org/doc/install/source#environment
> 
> So we have to use 5 for all softfloat architectures, no matter if they
> are ARMv5, v6 or v7 based.
> So only for ARMv6 and ARMv7 with hardfloat we would use a GOARM value of
> 6 and 7 respectively.
> 
> They also seem to use ARMv7 Data Memory Barrier instructions if GOARM==7
> https://github.com/golang/go/blob/master/src/runtime/asm_arm.s#L716

This is still not clear. 'use VFPv3' does not imply armhf ABI. You can mix
code that uses VFPv3 with code that only uses ARMv5 features, as long as
both use the same ABI (armel). But you cannot mix armel and armhf code.

None of these wiki pages make it really clear, what exactly is generated.
We need to take a closer look once we get there.

> Something else I forgot to mention:
> Since a few releases, Go is implemented in Go (and a little bit of asm)
> and no longer in C, which means, to build Go, you need to bootstrap it
> with a binary Go for your host architecture.
> They do release official Linux binaries for amd64, 386 and armv6l (with
> the l standing for little endian I assume)
> Do you think there are PTXdist users out there who are running it on
> non-amd64 hosts? What host platforms do we have to support?
> 
> Maybe we could also bootstrap it with gccgo (but then we would need a
> toolchain containing a GCC built with --enable-languages=c,c++,go).

I think we can rely on a host Go compiler to build 'our' Go compiler. We do
the same thing with the C compiler and similar things. I think we may want
to add it to 'ptxdist setup' or something like that, so that the user can
specify a defined version.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Clemens Gruber]

Hi,

On Thu, Oct 06, 2016 at 11:17:40AM +0200, Michael Olbrich wrote:
> This is still not clear. 'use VFPv3' does not imply armhf ABI. You can mix
> code that uses VFPv3 with code that only uses ARMv5 features, as long as
> both use the same ABI (armel). But you cannot mix armel and armhf code.

To determine the ABI, I built 3 different Go hello world binaries and
looked at the headers.

First I tried with file and readelf but that did not help much.
Only the entry points differ between GOARM=5 and GOARM=7.

1: env GOOS=linux GOARCH=arm GOARM=5 go build hello.go
file: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV)
readelf -h | grep Entry: 0x71620
readelf -h | grep Flags: 0x5000002, Version5 EABI, <unknown>

2: env GOOS=linux GOARCH=arm GOARM=6 go build hello.go
file: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV)
readelf -h | grep Entry: 0x693cc
readelf -h | grep Flags: 0x5000002, Version5 EABI, <unknown>

3: env GOOS=linux GOARCH=arm GOARM=7 go build hello.go
file: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV)
readelf -h | grep Entry: 0x69300
readelf -h | grep Flags: 0x5000002, Version5 EABI, <unknown>

--

Marc wrote that in armel, floating point values are passed via normal
32-bit registers (r0, r1, .. ?) instead of VFP registers (s0, s1, .. /
d0, d1, .. ?)

So I disassembled the hello world binaries..

All contain single- and double-precision VFP floating point register
accesses like the following:
112fc:      ed932a00        vldr    s4, [r3]

But the first binary, built with GOARM=5, always has a branch before
floating point instructions or floating point registers are used.
It looks like this:
112fc:      eb01823f        bl      71c00 <_sfloat>

After the jump to _sfloat there are no VFP register accesses, only
regular integer registers and non-VFP instructions.

The second and third one, built with GOARM=6 and 7 do not even have
_sfloat and seem to use VFP registers unconditionally.

--

So, does this mean that they use armel EABI for GOARM=5 to stay
compatible with softfloat but take advantage of VFP if it is available?
(Similar to the GCC option -mfpu=softfp?)

And armhf for GOARM=6 and GOARM=7 where they do not have a softfloat
fallback and also use ARMv7 instructions like dmb with GOARM=7.
(The latter does not occur in my basic hello world example)

If you want to have a look at the disassemblies, I uploaded them here:

Search for runtime.f32hash to see the differences I spoke of.
And take a look at line 100968 of the disassembly hello_goarm5.S to see
the _sfloat instructions.

GOARM=5
https://gist.githubusercontent.com/clemensg/66d44f4149f0f4b38810a95125369de1/raw/d931d0ce89cde08569abce939953270a71d1e560/hello_goarm5.S

GOARM=6
https://gist.githubusercontent.com/clemensg/72deef3935eb4a6549172ab8c8d54848/raw/a8b32d0811848c3a352a0a77cdcf863da88aba68/hello_goarm6.S

GOARM=7
https://gist.githubusercontent.com/clemensg/14a5b1d606c974bc5f2890f02afedcc7/raw/4bc269e93eb21486b8dfcef69f9f695c65a59093/hello_goarm7.S

> I think we can rely on a host Go compiler to build 'our' Go compiler. We do
> the same thing with the C compiler and similar things. I think we may want
> to add it to 'ptxdist setup' or something like that, so that the user can
> specify a defined version.

OK, sounds good.

Clemens

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Uwe Kleine-König]

Hello,

On Fri, Oct 07, 2016 at 06:47:27PM +0200, Clemens Gruber wrote:
> Marc wrote that in armel, floating point values are passed via normal
> 32-bit registers (r0, r1, .. ?) instead of VFP registers (s0, s1, .. /
> d0, d1, .. ?)
> 
> So I disassembled the hello world binaries..
> 
> All contain single- and double-precision VFP floating point register
> accesses like the following:
> 112fc:      ed932a00        vldr    s4, [r3]
> 
> But the first binary, built with GOARM=5, always has a branch before
> floating point instructions or floating point registers are used.
> It looks like this:
> 112fc:      eb01823f        bl      71c00 <_sfloat>
> 
> After the jump to _sfloat there are no VFP register accesses, only
> regular integer registers and non-VFP instructions.

I only took a quick look, but there is a return in _sfloat and after
that the VFP instructions are executed. And there are no conditional
instructions that would prevent a return. So unless I'm missing
something the ARMv5 code depends on kernel support.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Clemens Gruber]

Hi,

On Fri, Oct 07, 2016 at 08:37:55PM +0200, Uwe Kleine-König wrote:
> I only took a quick look, but there is a return in _sfloat and after
> that the VFP instructions are executed. And there are no conditional
> instructions that would prevent a return. So unless I'm missing
> something the ARMv5 code depends on kernel support.

They are doing something fancy here: They emulate the floating point
instructions and then overwrite the LR to avoid returning to those
hardfloat instructions.

See stepflt, _sfloat2 and sfloat2 in:
https://github.com/golang/go/blob/master/src/runtime/softfloat_arm.go

As well as _sfloat and _sfloatpanic in:
https://github.com/golang/go/blob/master/src/runtime/vlop_arm.s


So, we could start with letting the user choose the GOARM value manually
with explanations when to use which one:
GOARM=5 (>=ARMv5 && <=ARMv7, armel with softfloat emulation)
GOARM=6 (>=ARMv6 && <=ARMv7, armhf with VFPv1, but runs on VFPv2&3 too)
GOARM=7 (==ARMv7, armhf with VFPv3 only)

Note:
GOARM=5 works everywhere from ARMv5 to ARMv7 and does not require a VFP
unit and no kernel emulation, because all floating point calls are
emulated within Go itself. The linker inserts the call to _sfloat in
those binaries. See the links above for the implementation.


I think we could determine which GOARM version to use from both
PTXCONF_GNU_TARGET and PTXCONF_CROSS_GCC_CONFIG_EXTRA in
selected_toolchain/ptxconfig.
I'd definitely prefer the autodetection, because it is very confusing at
first which GOARM value is correct and why.

Bonus feature: Test compile a simple Go program which calls into a C
library from the project, e.g. glibc. Problem is, we can't execute it.
But at least we would have "some" problems detected by the linker. (?)

Thanks,
Clemens

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Clemens Gruber]

On Tue, Oct 11, 2016 at 06:18:26PM +0200, Clemens Gruber wrote:
> Hi,
> 
> On Fri, Oct 07, 2016 at 08:37:55PM +0200, Uwe Kleine-König wrote:
> > I only took a quick look, but there is a return in _sfloat and after
> > that the VFP instructions are executed. And there are no conditional
> > instructions that would prevent a return. So unless I'm missing
> > something the ARMv5 code depends on kernel support.
> 
> They are doing something fancy here: They emulate the floating point
> instructions and then overwrite the LR to avoid returning to those
> hardfloat instructions.

s/LR/PC/g

After the emulation, they increase the program counter to skip the
hardfloat instructions after returning from _sfloat.
https://github.com/golang/go/blob/master/src/runtime/softfloat_arm.go#L648

> 
> See stepflt, _sfloat2 and sfloat2 in:
> https://github.com/golang/go/blob/master/src/runtime/softfloat_arm.go
> 
> As well as _sfloat and _sfloatpanic in:
> https://github.com/golang/go/blob/master/src/runtime/vlop_arm.s
> 
> 
> So, we could start with letting the user choose the GOARM value manually
> with explanations when to use which one:
> GOARM=5 (>=ARMv5 && <=ARMv7, armel with softfloat emulation)
> GOARM=6 (>=ARMv6 && <=ARMv7, armhf with VFPv1, but runs on VFPv2&3 too)
> GOARM=7 (==ARMv7, armhf with VFPv3 only)
> 
> Note:
> GOARM=5 works everywhere from ARMv5 to ARMv7 and does not require a VFP
> unit and no kernel emulation, because all floating point calls are
> emulated within Go itself. The linker inserts the call to _sfloat in
> those binaries. See the links above for the implementation.
> 
> 
> I think we could determine which GOARM version to use from both
> PTXCONF_GNU_TARGET and PTXCONF_CROSS_GCC_CONFIG_EXTRA in
> selected_toolchain/ptxconfig.
> I'd definitely prefer the autodetection, because it is very confusing at
> first which GOARM value is correct and why.
> 
> Bonus feature: Test compile a simple Go program which calls into a C
> library from the project, e.g. glibc. Problem is, we can't execute it.
> But at least we would have "some" problems detected by the linker. (?)
> 
> Thanks,
> Clemens


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Uwe Kleine-König]

Hello,

On Wed, Oct 05, 2016 at 05:55:10PM +0200, Clemens Gruber wrote:
> 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)."

At least for Debian an ARMv6 compatible CPU (e.g. Raspberry Pi 1) cannot
run armhf. According to https://www.debian.org/ports/:

	A lot of modern 32-bit ARM boards and devices ship with a
	floating-point unit (FPU), but the Debian armel port doesn't
	take much advantage of it. The armhf port was started to improve
	this situation and also take advantage of other features of
	newer ARM CPUs. The Debian armhf port requires at least an ARMv7
	CPU with Thumb-2 and VFP3-D16 floating point support.

> 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?

Not necessarily. AFAIK given a properly configured kernel a hardfloat
instruction generates an exception that is then fixed up in the kernel.
It's not efficient but at least it works.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Go in ptxdist

[Marc Kleine-Budde]

[-- Attachment #1.1.1: Type: text/plain, Size: 1799 bytes --]

On 10/06/2016 08:33 AM, Uwe Kleine-König wrote:
> Hello,
> 
> On Wed, Oct 05, 2016 at 05:55:10PM +0200, Clemens Gruber wrote:
>> 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)."
> 
> At least for Debian an ARMv6 compatible CPU (e.g. Raspberry Pi 1) cannot
> run armhf. According to https://www.debian.org/ports/:

Cannot run debian's flavour of armhf, as it uses vp3 und thumb-2"

> 	A lot of modern 32-bit ARM boards and devices ship with a
> 	floating-point unit (FPU), but the Debian armel port doesn't
> 	take much advantage of it. The armhf port was started to improve
> 	this situation and also take advantage of other features of
> 	newer ARM CPUs. The Debian armhf port requires at least an ARMv7
> 	CPU with Thumb-2 and VFP3-D16 floating point support.

>> 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?
> 
> Not necessarily. AFAIK given a properly configured kernel a hardfloat
> instruction generates an exception that is then fixed up in the kernel.
> It's not efficient but at least it works.

armel passes floating point values in the integer registers and debian's
armhf passes them in floating point registers. This means you cannot mix
and match armel and armhf, as the are ABI incompatible.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de