New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: introduce build tags for different GOARM settings? #7211

Open
minux opened this Issue Jan 26, 2014 · 8 comments

Comments

Projects
None yet
6 participants
@minux
Member

minux commented Jan 26, 2014

now that the GOARM setting affects the code generated by the compiler,
which means we will need to have separate set of *.a files for each GOARM
anyway, why not introducing armv5, armv6 and armv7 build tags so that
we can statically select the best code based on target platform?

we probably should embed GOARM into cmd/go also, but that is also not
a problem, a lot of settings are embedded in cmd/go nowadays.
@rsc

This comment has been minimized.

Contributor

rsc commented Feb 10, 2014

Comment 2:

"Why not?" is not the right question.
The right question is "Why?".
@minux

This comment has been minimized.

Member

minux commented Mar 26, 2014

Comment 3:

According to Russ' comment in the golang-dev thread, this is deferred to Go1.4.
https://groups.google.com/forum/#!topic/golang-dev/1EERkkWgbrM

Labels changed: added release-go1.4, removed release-go1.3maybe.

@taruti

This comment has been minimized.

Contributor

taruti commented Apr 30, 2014

Comment 4:

I am using this functionality for ARMv4 things, with
http://s.violetti.org/go_build_gosubarch.diff.txt which implements the issue.
@minux

This comment has been minimized.

Member

minux commented Apr 30, 2014

Comment 5:

but we don't support ARMv4.
@rsc

This comment has been minimized.

Contributor

rsc commented Sep 15, 2014

Comment 6:

Labels changed: added release-none, removed release-go1.4.

@calmh

This comment has been minimized.

Contributor

calmh commented Dec 1, 2014

Comment 7:

> we probably should embed GOARM into cmd/go also
Can I just second this? For an application with auto update functionality, it needs to
know to download the armv5, armv6 or amrv7 binary. I handle this manually by setting an
extra variable at build time with -ldflags -X. But that requires *knowing* the correct
value of GOARM, which is only available if the user sets it manually. Figuring it out
when doing a native build on ARM is impossible as far as I can tell, since "go env"
doesn't print it. Grabbing the current architecture from uname is possible, but there's
nothing to say Go isn't compiled with GOAMR=5 on a GOARM=6 box...
@minux

This comment has been minimized.

Member

minux commented Dec 1, 2014

Comment 8:

"go env" doesn't print it, because the go tool doesn't know about GOARM at all. It's
a toolchain setting (5g/5a/5c/5l uses it, but not the go tool.)
It's the dist tool that detects the GOARM when doing native build, so "go tool dist env"
will show the current setting.
Decoding a suitable GOARM value from a running process it's easy. Open /proc/self/auxv
and parse the auxv for HWCAP. if HWCAP_VFPv3 is set, then it's 7, otherwise if only
HWCAP_VFP is set, it's 6; if neither is set, GOARM=5.
You can also grep for vfp and vfpv3 in /proc/cpuinfo. But the auxv is used directly by
the runtime to determine the compatibility of GOARM settings and the host system,
so it's more reliable. (I don't know if the hardware supports vfp, but kernel disables
vfp, should it be displayed in cpuinfo. I guess not, but it's better to use auxv for
sure.)
Parsing the auxv is easy, read src/runtime/os_linux_arm.c.
To get the goarm setting for current process, you need to read runtime.goarm, an
uint8 variable. It's possible if you know the trick (e.g. use assembly).

@minux minux added accepted labels Dec 1, 2014

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@maruel

This comment has been minimized.

Contributor

maruel commented Jan 4, 2018

I found a use case for adding build tag based on the specific ARM targeted version which helps answering the "why":

In the case of linking with a static library, I'd like to be able to select the optimal version of the static library, which is available in versions ARMv5 soft float, ARMv6 hard float, ARMv7 hf and ARMv8 hf.

I would use conditional compilation based on build tags to select the most optimal version. To be able to do that, I need a build tag for the ARM subarch.

For now I'll settle with ARMv6 hf which is the baseline I'm targeting for, but that's not optimal.

@ALTree ALTree added the NeedsDecision label Jan 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment