This week I was working on automating some toolchain tests and I’ve realized that we could greatly reduce the amount of setup done by the tester if we do ‘automagical’ guessing of the underlying processor architecture we’re running on, as well as the hardware capabilities (sets of instructions supported). Since then I was researching about good ways to get this information. One particularly interesting I found about were the ELF auxiliary vectors, described on this article.
ELF auxiliary vectors are carriers of information from kernel space to user space. They are loaded into the ELF program execution stack by the kernel ELF loader. The coolest thing is that we can see the contents of these vectors by setting the variable LD_SHOW_AUXV to 1 before executing any program. Let’s say, /bin/true:
lucas@freedomm:~$ LD_SHOW_AUXV=1 /bin/true
AT_HWCAP: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
So the info provided by this vector is reasonably safe, since it comes from the kernel itself. The main problem: older versions of the 2.6 kernel won’t support all the variables we’re interested in, such as AT_PLATFORM, which reports, unsurprisingly, the processor architecture.
Meanwhile, I’m going with the poor’s man solution: simple parse of /proc/cpuinfo. That’s good enough for now, but if someone wants to show a reasonably robust and prevalent way of getting CPU information and hardware capabilities, please let me know.