|
From: Peter B. <be...@vn...> - 2015-04-13 17:45:47
|
On Sat, 2015-04-11 at 16:36 -0700, John Reiser wrote: > > On MIPS (ASUS RT-N16): > > $ LD_SHOW_AUXV=1 /bin/true | grep AT_HWCAP > > ### empty output from grep: no AT_HWCAP at all > > ... because the C library is uClibc, not glibc. Yes, the above is a neat trick from glibc. On linux, the AUXV is exported from the kernel via /proc/<pid>/auxv or /proc/self/auxv and it is also placed on the stack above the top most frame. We (IBM) also created a libauxv library which can help with reading and querying the AUXV contents: https://github.com/Libauxv/libauxv > Some digging shows that the AUX vector is: > 0x00000010 AT_HWCAP 0x00000000 [snip] > Still, AT_HWCAP is 0, which omits information such as support for mips16 and dsp > that is shown in /proc/cpuinfo below. The Linux kernel is 2.6.24 (dd-wrt + optware.) That seems like a kernel bug to me. > From the viewpoint of the end user, a commandline override such as --cpu=... > has an advantage because it allows working around bugs in AT_HWCAP > and/or /proc/cpuinfo. You'll get no argument from me on it being potentially useful to override the automatically detected cpu value. Peter |