Build for pihole-FTL ARM soft-float

In the latest release of FTL (v5.2): https://github.com/pi-hole/ftl/releases there are 3 ARM builds:
pihole-FTL-arm-linux-gnueabi
pihole-FTL-arm-linux-gnueabihf
pihole-FTL-armel-native

Analyzed them with readelf command and it seems that both first two are hard-float and last is soft-float.

Question 1: Shouldn't pihole-FTL-arm-linux-gnueabi be soft-float ?

I do have an armv5 machine which is soft-float. Output of uname -a:
Linux debian-nas 4.20.6-kirkwood-tld-1 #1 PREEMPT Thu Jan 31 21:41:45 PST 2019 armv5tel GNU/Linux

When I'm installing pihole it downloads and installs pihole-FTL-arm-linux-gnueabi which is hard-float does not work on a soft-float machine.

Question 2: Is this a bug or is it normal ? I don't know if that build should either be soft-float or the installer detects the architecture wrong.

Finally, I checked out the source code at V5.2, built and installed the pihole-FTL binary and everything is working fine, but every time I do a pihole reconfigure (needed to fix when I mess up something) the installer states: Corruption detected and reinstalls again the wrong binary for my architecture.

So, Question 3: What can I do for the installer to not detect the binary as corrupted when is built and installed locally ?

Thanks :slight_smile:

Pogoplug?

No, Lenovo IX2 NG flashed with Debian 10.

These notations come from the days of when Pi-hole was still Raspberry Pi-focused. The Raspbian foundation denotes

  • arm-linux-gnueabi -> ARMv6 with hard-float (BCM2835 as used in Zero and Model 1)
  • arm-linux-gnueabihf -> ARMv8 with hard-float (BCM2837, BCM2837B0, BCM2711 as used in Model 2 B v1.2, 3 and 4)

since we use their official cross-compilers, this is what these point to. They all have hardware vector floating point support

This is intentional, see the reasons above.

Not much. However, you are not the first one to request support for ARMv5TE processors. We should not change our regular pihole-FTL-arm-linux-gnueabi from v6 hard-float to v5TE soft-float as this may lead to a significant drop in performance. However, I'm of good cheer that we can add a v5TE build on top. Stay tuned to this space for updates.

Thanks for the great explanations.

But still, in this case, shouldn't the installer download the pihole-FTL-armel-native binary when running on an ARMV5 ?

is

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_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  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_enum_size: int

so no. At least not how it is currently built.

The reason is that the multiarch/debian-bootstrap container is an armv7l emulation:

$ docker run -it --rm multiarch/debian-debootstrap:armel-stretch-slim
root@d471d2b8697c:/# uname -a
Linux d471d2b8697c 5.4.0-45-generic #49~18.04.2-Ubuntu SMP Wed Aug 26 16:29:02 UTC 2020 armv7l GNU/Linux

I did some research on this and after some tweaking, the debian-armel build is now v4T-compliant:

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "4T"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  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_enum_size: int

I guess that's the way to go then. This binary will run on all ARM machines being able to run a Debian image.

I see. So as far as I can tell that should work on armv5te although it's not the right build.

Also, I don't know the build system process in this project, but I do have a buildroot setup used to crosscompile for this arch so if I can support with the buildroot config, a docker image with the toolchain and/or testing I would be glad to.

LE: Nevermind this, just saw your last post :+1:

Yes, that looks good. But I did not quite understand, did you manage to build this binary in the armv7l container ?

Yes, even when the emulated machine is a ARMv7 one, I can instruct the compiler to avoid opcodes that are only available in more recent processors. This time, I specifically asked the compiler to compile for ARMv5TE and the resulting binary was even ARMv4T.

You can compare the ARMv7 (page 25ff) and the ARMv4T instruction set if you want to know more.

1 Like

Great info :+1:

I guess in the next release there should be a binary for armv4t and armv5te so this topic may be closed.

Thanks.

Yes, after

has been merged, the development branch will already have a armv4t+-complaint binary. This will then automatically extend to the next release version as well.

@Feldwebel I'm currently improving the automatic detection of which binary is to be used (this is less trivial than one would naively assume...).

Can you give me the output of the following commands?

uname -m | sed "s/[^0-9]//g;"
ldd /bin/ls | grep -E '^\s*/lib' | awk '{ print $1 }'

It should be

5
/lib/ld-linux.so.3

for you.

Sure thing.

feldwebel@debian-nas:~$ uname -m | sed "s/[^0-9]//g;"
5
feldwebel@debian-nas:~$ ldd /bin/ls | grep -E '^\s*/lib' | awk '{ print $1 }'
/lib/ld-linux.so.3

The mentioned PR was superseded by

to have binaries with maximum performance for all ARM binaries around there.