Comment 2:

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

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.

Comment 4:

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

Comment 5:

but we don't support ARMv4.

Comment 6:

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

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

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

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.

In writing some assembly-optimised libraries for Go, I found this issue. It would be really great to have a way to conditionally compile code based on GOARM and the upcoming GOAMD64 so I don't have to do a dynamic dispatch at runtime.

Related: #22106

I believe this was implemented in #45454