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.

mhorne added inline comments.Aug 11 2020, 7:36 PM

sys/arm64/include/elf.h
122 ↗	(On Diff #75696)	For reference: https://github.com/torvalds/linux/blob/master/arch/arm64/include/uapi/asm/hwcap.h

mhorne added a child revision: D26031: arm64: export new HWCAP features.Aug 11 2020, 7:37 PM

emaste accepted this revision.Aug 11 2020, 8:41 PM

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

markj added inline comments.Aug 11 2020, 9:19 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?

emaste added inline comments.Aug 11 2020, 9:36 PM

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 `#define`s. 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 accepted this revision.Aug 12 2020, 7:24 AM

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).

mhorne added inline comments.Sep 2 2020, 3:01 PM

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.

markj added inline comments.Sep 2 2020, 3:45 PM

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.

mhorne added inline comments.Sep 2 2020, 5:25 PM

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.

markj added inline comments.Sep 2 2020, 7:37 PM