x/sys/unix: access to ELF auxiliary vector

Proposal Details

like os.Args and os.Environ, I was wondering why there is neither an API to get ELF auxiliary vector nor Aux type. C does provide them in Elf.h

[ianlancetaylor]

If we do this I think it should be in the golang.org/x/sys/unix package. The os package is mainly aimed at OS-independent functionality, but auxv is specific to ELF-based systems.

so, in the current state of art, is there no way to get the full aux vector?

[ianlancetaylor]

As far as I know there is not.

[adonovan]

so, in the current state of art, is there no way to get the full aux vector?

Not from Go. In C you can usually derive it from the address of the environ symbol, but it may be non-portable.

[seankhliao]

I see runtime has an internal sysauxv which x/sys/cpu hooks into, falling back to /proc/self/auxv. Is the proc file sufficient?

/proc/self/auxv

could you provide a minimal example on how to retrieve auxv values?

[seankhliao]

see https://go.googlesource.com/sys/+/9a28524796a519b225fedd6aaaf4b1bf6c06c002/cpu/hwcap_linux.go#26

[florianl]

#68089 advocated to expose runtime.getAuxv() and make it a public API. Exposing the auxiliary vector via os was not considered as a viable option, as os should be more of a higher level layer with cross OS compatability.
But adding a public API, like runtime.Getauxv(), would also introduce some kind of OS specifics into runtime.

An alternative, also mentioned in #67839 (comment) and go.dev/cl/458256, could be an exposure of the auxiliary vector via golang.org/x/sys. golang.org/x/sys is OS specific and therefore a perfect fit. The unknown for me in this approach is how golang.org/x/sys can get access to something, that only runtime knows about, without techniques like //go:linkname.