[Openmcl-devel] deprecated linker options when targeting macOS 13; also potential ARM64 issues

[Tim McNerney]

Offhand, it sounds like we need to go with the flow and burn a “page zero” register. As you well know, fixed code addresses are becoming frowned upon in security circles, and Apple‘s “architecture policy” engineers probably never considered CCL’s implementation cleverness, since they only think about their own homebrew languages and maaaybe other languages most commonly used by their customers. 

--Tim

> On Apr 24, 2024, at 15:04, R. Matthew Emerson <rme at clozure.com> wrote:
> 
> 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’m 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’m 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’ll be in some trouble.
> 
> As long as we pass, say, -mmacos-version-min=10.15, then we don’t get the warnings, but future problems often arrive before you know it.
> 
> I guess I’d 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.”
> 
> If that’s 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-time-compilers-to-apple-silicon)
> 
> 
> 
> 
> 
>