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
Unknown Object (File)
Sun, Dec 1, 3:41 PM
Unknown Object (File)
Mon, Nov 25, 8:41 PM
Unknown Object (File)
Mon, Nov 25, 4:28 AM
Unknown Object (File)
Sun, Nov 24, 8:41 AM
Unknown Object (File)
Sat, Nov 23, 5:54 AM
Unknown Object (File)
Thu, Nov 21, 6:32 AM
Unknown Object (File)
Tue, Nov 19, 7:37 PM
Unknown Object (File)
Fri, Nov 15, 9:30 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 Not Applicable
Unit
Tests Not Applicable

Event Timeline

Makefile.inc1
1089–1090

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
150

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–301

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
1089–1090

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
150

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
1089–1090

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
150

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
1089–1090

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

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

lib/Makefile
206

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

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