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

Offhand, it sounds like we need to go with the flow and burn a =E2=80=9Cpage=
 zero=E2=80=9D register. As you well know, fixed code addresses are becoming=
 frowned upon in security circles, and Apple=E2=80=98s =E2=80=9Carchitecture=
 policy=E2=80=9D engineers probably never considered CCL=E2=80=99s implement=
ation cleverness, since they only think about their own homebrew languages a=
nd maaaybe other languages most commonly used by their customers.=20

--Tim

> On Apr 24, 2024, at 15:04, R. Matthew Emerson <[email protected]> wrote:
>=20
> =EF=BB=BFIn 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 t=
ools and targeting macOS 13.
>=20
> The alignment ones we can deal with. The other warnings I=E2=80=99m more w=
orried about.
>=20
> 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 macO=
S 13.0 or later
>=20
> We can use the -no_fixup_chains linker option to silence the chained fixup=
 warnings.  That means our link command would look like this:
>=20
> cc -Wl,-no_fixup_chains,-no_pie,-pagezero_size,0x10000,-seg1addr,0x10000 .=
..
>=20
> 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.
>=20
> 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.
>=20
> I guess I=E2=80=99d better ask Apple at some point soon.
>=20
> I also just ran across https://developer.apple.com/forums/thread/655950, w=
hich says "Modifying pagezero_size isn't a supportable option in the arm64 e=
nvironment. arm64 code must be in an ASLR binary, which using a custom pagez=
ero_size is incompatible with. An ASLR binary encodes signed pointers using a=
 large random size along with the expected page zero size, and this combinat=
ion is going to extend beyond the range of values covered in the lower 32-bi=
ts.=E2=80=9D
>=20
> If that=E2=80=99s the case, then that may be an exciting problem for an AR=
M64 port (well, an Apple silicon port in particular, I suppose). Maybe we gi=
ve up on controlling low memory and burn a register to point at the necessar=
y data.
>=20
> (There will also be certain hoops to jump through as described in https://=
developer.apple.com/documentation/apple-silicon/porting-just-in-time-compile=
rs-to-apple-silicon)
>=20
>=20
>=20
>=20
>=20
>=20