On Fri, Mar 23, 2012 at 3:21 AM, Wookey <[email protected]> wrote:
> The set of packages you install and the set of packages linked-against
> will be the same, except for static linking, and I beleive that to be
> very rare, quite possibly non-existent in a base install. So I don't
> think this issue meaningfully changes your problem-size.
>
I came across something that should help significantly with the problem of
determining if there is ARMv7 code leakage into my recompiled armhf
packages that should be ARMv6 pure.
Basically, I can use the 'readelf -A' command to determine when a v6
executable has been linked against a v7 static library, thus causing
contamination of v7 code into my packages.
It seems to work as follows. Below, in my armhf v6 chroot environment I
compiled the hello.c program using my rebuilt v6 gcc and linked it against
the rebuilt v6 standard C libraries. As shown below 'readelf -A' does
indeed properly report the resulting binary as pure v6 code.
———————————————
$ cat hello.c
#include <stdio.h>
int main()
{
printf("Hello world.\n");
return 0;
}
$ gcc -c hello.c
$ gcc -o hello hello.o
$ readelf -A hello
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
$
———————————————
Below, I went outside my chroot environment and simply linked the same v6
hello.o file created above with the standard armhf v7 standard C library.
Indeed, the resulting binary is now flagged as being v7. Because the v6
object file was linked against a v7 library, the binary is now flagged as
being v7 code.
———————————————
$ gcc -o hello hello.o
$ readelf -A hello
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
$
———————————————
The result of this means that it should be fairly straight forward to
create a filter for every v6 armhf package created for the Raspberry Pi
platform to flag and reject packages that have been contaminated with v7
code. This still doesn't tell me the exact source of the contamination
(ie. which library caused the problem), but that shouldn't be too difficult
to find out. This may also serve to filter out any v7 binaries caused by
v7 assembly instructions or unexpected manipulation of the gcc options to
produce v7 code (but I have to test this out).
Although I haven't yet created an automated test script, I was able to
manually use 'readelf -A' to determine that a number of the binaries I
created as I recompiled packages have v7 code leaking into them. I was
able to fix this by going back and correcting the libraries they link
against to be v6 code and then verified the newly created packages were
pure v6 code.
Unless there is something I'm overlooking, I should now be able to
recompile armhf packages for ARMv6+VFP and be reasonably confident they
will run on the Raspberry Pi platform without actually having to smoketest
every package. Of course, they'll all be tested in the end on the actual
platform, but this should aid my build process.
Is there anything I'm overlooking here?
Mike
