x/sys/unix: Missing constants for fadvise() for Linux/arm

[fd0]

This is a followup-issue for #15114, which added constants for the Fadvise() syscall for amd64 and 386 on Linux. I discovered that the constants are also missing for Linux/arm. For all the other architectures they are there, only arm is missing.

I've tried running mkall.sh but this fails:

$ GOOS=linux GOARCH=arm ./mkall.sh
gcc: error: unrecognized command line option '-marm'; did you mean '-mabm'?
gcc: error: unrecognized command line option '-marm'; did you mean '-mabm'?
fork/exec /tmp/go-build154582490/command-line-arguments/_obj/exe/mkpost: exec format error

Is mkall.sh supposed to be run on the target architecture?

I propose adding the constants FADV_* manually to ztypes_linux_arm.go, the constants are the same: https://github.com/thorvalds/linux/blob/master/include/uapi/linux/fadvise.h

Would a CL which adds the constants manually be accepted?

Could you please advise me how to add the constants for Linux on arm?

[bradfitz]

Would a CL which adds the constants manually be accepted?

That adds maintenance pain for everybody in the future when your manual edits would keep getting auto-removed, and people would have to keep manually adding them back.

Related: #15282

/cc @ianlancetaylor

[fd0]

Ok, I understand. If there is anything I can do to help (at least anything that's not "refactor this all"), please let me know.

[bradfitz]

Actually, let's just separate out the hand-written files. As long as you don't manually touch the machine-generated ones we should be fine.

Feel free to send CLs adding to or creating syscall_linux_arm64.go or whatever the manual files are.

[fd0]

That would work for now, adding the constants manually to a new file types_linux_arm.go. But since types_linux.go contains the FADV_* constants, the next time mkall.sh is run for/on Linux/arm, they will also be written to ztypes_linux_arm.go and the code won't compile any more.

In order to mitigate this, the constants need to be removed from types_linux.go (the "template") and ztypes_*.go.

I'd really like to solve my problem here, but I don't that this is a good idea.

How is mkall.sh supposed to work? Is it required to execute it on the target platform?

If I understood @ianlancetaylor in #15114 (comment) correctly, rebuilding the machine generated files produces many unrelated changes (which confirms my observations).

[ianlancetaylor]

You shouldn't need to change types_linux.go or add types_linux_arm.go. Just run mkall.sh on a ARM GNU/Linux system. Then manually revert the unrelated changes.

[fd0]

Ok, I'll see if I can get access to some box on ARM.

[fd0]

Submitted as https://go-review.googlesource.com/31641

[gopherbot]

CL https://golang.org/cl/31641 mentions this issue.