Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make arm-qemu builds ARMv4T compliant (was ARMv6) to support more devices #902

Closed
wants to merge 4 commits into from

Conversation

DL6ER
Copy link
Member

@DL6ER DL6ER commented Oct 12, 2020

By submitting this pull request, I confirm the following:

  • I have read and understood the contributors guide.
  • I have checked that another pull request for this purpose does not exist.
  • I have considered, and confirmed that this submission will be valuable to others.
  • I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
  • I give this submission freely, and claim no ownership to its content.

How familiar are you with the codebase?:

10


Explicitly specify the building host to achieve true ARM Debian compliance with the cross-compiled build. We remove concurrent building of the dependencies as this can lead to compiler segmentation faults on many-core machines with a lot of concurrency in the emulator.

Even though this build only requested ARMv5 compliance, the produce code actually generated a binary that is even ARMv4T complaint:

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

Even when this is not the expected outcome, any ARMv5TE processor will be able to run ARMv4T code. And as the compiler generated ARMv4T code while it was allowed to generate ARMv5TE means that, despite the fact that all compiler optimizations are enabled, no ARMv5TE-specific instructions are useful here and the generation of ARMv4T-compliant code is not slower by any means (due to missed optimizations).

The PR updating the FTL builds for ARMv4T-compliance will also address the changed architecture in the tests. This has to come after this PR was merged.

@pralor-bot
Copy link

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/build-for-pihole-ftl-arm-soft-float/39254/19

@DL6ER DL6ER removed the request for review from dschaper October 12, 2020 10:29
@DL6ER DL6ER marked this pull request as draft October 12, 2020 10:29
@DL6ER
Copy link
Member Author

DL6ER commented Oct 12, 2020

Putting this on hold right now, it seems we might have found a variant without the arm-qemu build. This does not only reduce the number of builds (and, hence, code and management complexity) but also reduce the overall compile time on the CI from some 15-20 minutes down to less than 3 which is very nice.

@DL6ER DL6ER changed the title Make arm-qemu builds ARMv4T compliant (was ARMv6) to support more devices Support more devices by providing additional ARMv4 and ARMv5 binaries Oct 13, 2020
@DL6ER DL6ER changed the title Support more devices by providing additional ARMv4 and ARMv5 binaries Support more devices by providing ARMv4 and ARMv5 binaries Oct 13, 2020
@DL6ER DL6ER force-pushed the new/ARMv4T-compliance branch from d00534c to 81694ea Compare October 13, 2020 05:41
@DL6ER DL6ER changed the title Support more devices by providing ARMv4 and ARMv5 binaries Make arm-qemu builds ARMv4T compliant (was ARMv6) to support more devices Oct 13, 2020
@DL6ER
Copy link
Member Author

DL6ER commented Oct 14, 2020

Superseded by #903

@DL6ER DL6ER closed this Oct 14, 2020
@DL6ER DL6ER deleted the new/ARMv4T-compliance branch October 14, 2020 05:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants