Page MenuHomeFreeBSD

arm64: update the set of HWCAP definitions
ClosedPublic

Authored by mhorne on Aug 11 2020, 7:23 PM.

Details

Summary

This is in sync with what is defined for Linux 5.8. Note that all bits
in HWCAP are exhausted, and HWCAP2 has been added.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

sys/arm64/include/elf.h
122 ↗(On Diff #75696)

You'll notice I've skipped one bit here. The reason for this is that I'd like the new definitions to have the same values that Linux does. We are missing a definition for HWCAP_ASIMDHP, and as a result a portion of our HWCAP values (from CPUID to FLAGM) differ from what Linux defines by one bit.

I'm not sure how this problem should be solved. We could simply add a definition for HWCAP_ASIMDHP and accept that the values will be different between platforms, or we could bump __FreeBSD_version and fix the definitions going forward. An argument for the latter is that it would allow us to expose AT_HWCAP in the linuxulator for free.

emaste added inline comments.
sys/arm64/include/elf.h
122 ↗(On Diff #75696)

we could bump __FreeBSD_version and fix the definitions going forward

I would lean towards this option - it's awkward in the short-term but I'd still prefer it now before the platform becomes tier 1. I'm not sure about stable/12 vs current though.

All of that said as far as I can tell there are no consumers in the base system, and 3rd party software consumers I found are generally toolchain components. We might be able to just make the change, bump __FreeBSD_version, and not think about it any more.

This revision is now accepted and ready to land.Aug 11 2020, 8:41 PM
sys/arm64/include/elf.h
122 ↗(On Diff #75696)

How exactly are the values used in toolchain components? It is generally helpful for FreeBSD 12 binaries to work on later versions, even if it's not officially supported. Will the breakage be dramatic?

sys/arm64/include/elf.h
122 ↗(On Diff #75696)

I'm not entirely sure - I just found some references via Debian's code search, and the ones I looked at in any detail were just instances of #defines. I did not look too hard, but did not find any real consumers.

I'd add a comment explaining the gap.

sys/arm64/include/elf.h
122 ↗(On Diff #75696)

I guess it would not be too difficult to translate HWCAPs to their old values for FreeBSD 12 compat, should it become necessary.

manu added inline comments.
sys/arm64/include/elf.h
122 ↗(On Diff #75696)

I've probably missed HWCAP_ASIMDHP when I did the original code, I agree with @markj we could had compat code if something needs it (I think we will be ok tbh).

sys/arm64/include/elf.h
122 ↗(On Diff #75696)

If we were to provide compat code for this, how could it be done? We could perform the fixup in elf_aux_info(3), but I'm not sure how to determine if we are running a FreeBSD 12 executable from that context.

Despite this question, I also think we would be fine just changing the definitions.

sys/arm64/include/elf.h
122 ↗(On Diff #75696)

I think it could be conditional on curproc->p_osrel. We seem to have done something similar with P_OSREL_POWERPC_NEW_AUX_ARGS.

sys/arm64/include/elf.h
122 ↗(On Diff #75696)

Thanks. I think I see how it could be done, but it would involve duplicating most of the logic in freebsd_copyout_auxargs, as they do in this powerpc case.

I think I will commit this change, and put up another that fixes the definitions without any compat. If there are no objections, we can eventually MFC that fix to stable/12 and wash our hands of it. Let me know if that seems unreasonable.

I think I will commit this change, and put up another that fixes the definitions without any compat. If there are no objections, we can eventually MFC that fix to stable/12 and wash our hands of it. Let me know if that seems unreasonable.

That sounds reasonable to me. I'm almost certain there will be no fallout or objection.

You might want to put a /* XXX comment where the bits diverge though, with the explanation from the comments in this review. If nothing else it might be useful if we end up with different definitions in 12 and 13.

sys/arm64/include/elf.h
122 ↗(On Diff #75696)

Sounds reasonable to me.

This revision was automatically updated to reflect the committed changes.