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.
———————————————
$ 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.