deprecated linker options when targeting macOS 13; also potential ARM64 issues

"R. Matthew Emerson" <[email protected]> Wed, 24 Apr 2024 12:04:27 -0700
Newsgroups gmane.lisp.openmcl.devel
Message-ID <[email protected]>
In https://github.com/Clozure/ccl/issues/457, the reporter shows a bunch =
of scary warnings when trying to build the lisp kernel with Xcode 15 =
tools and targeting macOS 13.

The alignment ones we can deal with. The other warnings I=E2=80=99m more =
worried about.

ld: warning: prefered load addresses (-seg1addr) are disabled with =
chained fixups
ld: warning: -no_pie is deprecated when targeting new OS versions
ld: warning: prefered load addresses (-seg1addr) are disabled with =
chained fixups
ld: warning: non-standard -pagezero_size is deprecated when targeting =
macOS 13.0 or later

We can use the -no_fixup_chains linker option to silence the chained =
fixup warnings.  That means our link command would look like this:

cc -Wl,-no_fixup_chains,-no_pie,-pagezero_size,0x10000,-seg1addr,0x10000 =
...

But I=E2=80=99m not sure what to do about the warnings about -no_pie and =
-pagezero_size. CCL wants to have some stuff laid out in fixed locations =
in (relatively) low memory.  If Apple gets rid of those options, I think =
we=E2=80=99ll be in some trouble.

As long as we pass, say, -mmacos-version-min=3D10.15, then we don=E2=80=99=
t get the warnings, but future problems often arrive before you know it.

I guess I=E2=80=99d better ask Apple at some point soon.

I also just ran across https://developer.apple.com/forums/thread/655950, =
which says "Modifying pagezero_size isn't a supportable option in the =
arm64 environment. arm64 code must be in an ASLR binary, which using a =
custom pagezero_size is incompatible with. An ASLR binary encodes signed =
pointers using a large random size along with the expected page zero =
size, and this combination is going to extend beyond the range of values =
covered in the lower 32-bits.=E2=80=9D

If that=E2=80=99s the case, then that may be an exciting problem for an =
ARM64 port (well, an Apple silicon port in particular, I suppose). Maybe =
we give up on controlling low memory and burn a register to point at the =
necessary data.

(There will also be certain hoops to jump through as described in =
https://developer.apple.com/documentation/apple-silicon/porting-just-in-ti=
me-compilers-to-apple-silicon)