On Thu, Apr 26, 2012 at 2:40 PM, Wookey <woo...@wookware.org> wrote: > The right way to do this is with HWCAPS bits to identify whether the > hardware can run v7 binaries and for dpkg to refuse to install stuff > that won't run. > > This is how it works on x86: > http://developers.sun.com/solaris/articles/hwcap_modification.html > with HWCAPS for cmov and cmpxchg16b > > However I'm not sure the arm HWcaps list: > http://lxr.free-electrons.com/source/arch/arm/include/asm/hwcap.h?v=2.6.30 > actually covers the extra v7 instructions. You could probably use the > VFP3 CAP as a proxy on PI, but it may be better to define an actual > 'has v7 ISA' bit) >
Somehow I don't think the armhf people would be too happy about rebuilding all their packages to accommodate the Raspberry Pi as it would be those packages that would have to include 'has v7 ISA' bit. > So to use this mechanism would need the kernel to check for only-on-v7 > instructions and set/not-set the bit. Then arrange for packages to > have needed HWCAPS set in metadata for dpkg to check. > This would prevent the kernel from executing the binary, but this would still leave us in the boat that if the binaries get on the system they could leave the system in an un-runnable state. It's just the kernel refuses to load the binary rather than the binary generating an illegal instruction. Still, it's useful the kernel can prevent execution of the binaries as its definitely more graceful way to catch code that can't execute. > As this data is not already present in everyone else's packages > you'd be best just adding it for the PI packages you've built. > > Which of course means you could actually use any old item of metadata > 'X-package-ISA:v6' and check that, refusing to install anything else, > rather than a properly general HWCAPS method. But doing it right would > be generalisable to many problems of this class (multimedia-optimised > libraries, with without/NEON etc). > Right now, as I'm building armv6 packages I use a perl script and 'readelf' to scan each elf/library file in the package for v7 file attributes signature. Readelf will tell me the following for armv7 elf files: Attribute Section: aeabi File Attributes Tag_CPU_name: "7-A" Tag_CPU_arch: v7 Tag_CPU_arch_profile: Application Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-2 Tag_FP_arch: VFPv3-D16 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: int Tag_ABI_HardFP_use: SP and DP Tag_ABI_VFP_args: VFP registers Tag_DIV_use: Not allowed For armv6 elf files, it reports the following: Attribute Section: aeabi File Attributes Tag_CPU_name: "6" Tag_CPU_arch: v6 Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 Tag_FP_arch: VFPv2 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: int Tag_ABI_HardFP_use: SP and DP Tag_ABI_VFP_args: VFP registers Tag_DIV_use: Not allowed I'm assuming I could create a special Raspberry Pi version of dpkg which would perform this test at download time and abort the installation if binaries with 'Tag_CPU_arch: v7' were found. I realize it's short circuiting the more formal HWCAPS method, but it seems to me it would yield similar capability. Also, I wonder if the kernel is exposed to the 'Tag_CPU_arch:' setting in the elf as it is loaded. If so, the kernel on the Raspberry Pi could prevent loading v7 binaries without necessarily going the full HWCAPS route. Mike
