Page MenuHomeFreeBSD

arm64 lib32: enable building of lib32 on arm64
ClosedPublic

Authored by karels on Jul 8 2023, 10:19 PM.
Tags
None
Referenced Files
F102611392: D40945.diff
Thu, Nov 14, 6:58 PM
Unknown Object (File)
Thu, Oct 17, 6:34 AM
Unknown Object (File)
Thu, Oct 17, 12:26 AM
Unknown Object (File)
Oct 15 2024, 8:50 PM
Unknown Object (File)
Oct 13 2024, 3:08 PM
Unknown Object (File)
Oct 12 2024, 5:40 AM
Unknown Object (File)
Oct 10 2024, 10:05 PM
Unknown Object (File)
Oct 8 2024, 5:29 PM
Subscribers

Details

Summary

Enable LIB32 option on aarch64, defaulting to YES; it had defaulted
to "broken". Add required variables for how to compile lib32 on
arm. Use /usr/include/arm for armv7 (32-bit) headers, analogous to
/usr/include/i386 on amd64. Omit libomp from lib32; it is not
supported on armv7.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 52517
Build 49408: arc lint + arc unit

Event Timeline

Makefile.inc1
1084

Can we hoist some kind of:

.if ${TARGET_ARCH} == "amd64"
LIBCOMPAT_INCLUDE_DIRS+=i386
.elif ${TARGET_CPUARCH} == "aarch64"
LIBCOMPAT_INCLUDE_DIRS+=arm
.endif

so then these all become a single generic

.for d in ${LIBCOMPAT_INCLUDE_DIRS)
...
.endfor

rather than having N copies of the same pattern?

Ideally that'd be a separate change without the aarch64 bit and then this would just add to that.

share/mk/bsd.compat.mk
146

Doesn't your driver fix render this obsolete? We don't want this hack in the tree.

share/mk/src.opts.mk
301

${__T:Maarch64*} would be more friendly to CheriBSD as we have other arm64 MACHINE_ARCHes

lib/Makefile
207

This also belongs in src.opts.mk for marking OPENMP broken in the same place arm does. I guess so should the powerpc check, really. Though I'll note I'm changing COMPAT_32BIT checks to be COMPAT_LIBCOMPAT == "32" (see https://reviews.freebsd.org/D40922) and that patch series will likely land before this one.

emaste added inline comments.
Makefile.libcompat
7

Same comment as below about keeping in sync

share/mk/src.opts.mk
300

I think it's better to just drop these sorts of comments rather than updating to keep them in sync, or just change to something like "LIB32 is supported on a subset of architectures."

Makefile.inc1
1084

The change seems reasonable; it could be folded into existing tests in bsd.compat.mk. It seems a little odd to change it ahead of time, though, as amd64 will be the only case at first.

lib/Makefile
207

Any plans on when to push that series? Looks like they are all approved. It would be easier for me to finish after that is in the tree.

OPENMP isn't marked broken for arm, just defaults to no. But it is broken. I see that I can simplify this test slightly by testing MACHINE_ARCH for armv7.

share/mk/bsd.compat.mk
146

I think that depends on whether a bootstrap compiler is built. If that is the only change, I don't think it is. I had no problem on a machine doing cross-compiles and clang 15.x installed, but Mark Millard had problems on an arm64 with clang 16.0 without this change. (I had omitted it after adding the clang change.)

Makefile.inc1
1084

On its own, sure, but as a preparatory commit for this I don’t think so. It’s the usual approach of “NFC refactor then extend”.

lib/Makefile
207

One of the reviews was still undergoing (ill-informed) debate when I commented this last night, but I plan to push it either later today or during the work day tomorrow, so shouldn’t be holding you up.

share/mk/bsd.compat.mk
146

We can patch the ports compilers to do it, and can bump the version for the in-tree compiler so it’s bootstrapped. I’m loathe to add a hack like this here if we can avoid it, which we should be able to.

Makefile.inc1
1084

I thought to put the definition(s) in bsd.compat.mk, but that isn't included in Makefile.inc1. I'll put the definitions in Makefile.inc1 unless someone has a better idea.

rebase, updates, implement reviewer suggestions

lib/Makefile
206–207

Technically doesn't matter now we don't have v6 in-tree, but ${MACHINE_CPUARCH} != "arm" is what we use elsewhere

lib/Makefile
206–207

I can change it if you prefer/if it is more correct. btw, I looked at src.opts.mk, and I don't know why the existing rules there are not sufficient. I suspect that the wrong architecture is defined when src.opts.mk is included.

lib/Makefile
206–207

The compat + src.opts.mk story is a bit of a mess currently

share/mk/bsd.compat.mk
69

Missed COMPAT_CPUTYPE -> LIB32CPUTYPE in your rebase

72

Ditto

share/mk/bsd.compat.mk
69

Oops, thanks for catching.

This revision is now accepted and ready to land.Jul 12 2023, 6:05 PM