static-cons memory read error using saved acl2 image on FreeBSD 13+

[xrme]

static-cons memory read error using saved acl2 image on FreeBSD 13+

[xrme]

It is sufficient to start up with ccl -I saved_acl2.fx86cl64 to show that (ccl:static-cons 1 2) fails.

[xrme]

Other observed weirdness:

? (ccl:static-cons 1 2)
(1 . 2)                         ;it works?
? (ccl:static-cons 1 2)
> Error: The value #<Package "X86"> is not of the expected type LIST.
> While executing: STATIC-CONS, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
                                ;nope, it doesn't work

? (ccl:static-cons 1 2)
(1 . 2)
? (ccl:static-cons 1 2)
> Error: The value #<Unbound> is not of the expected type LIST.
> While executing: STATIC-CONS, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.

[xrme]

Doing (gc) first thing after starting up the lisp seems to avoid all of these problems, so maybe some kind of initialization bug?

[xrme]

It may be that FreeBSD's ASLR implementation (which is the default on 64-bit since 13.2) is the culprit here.

[xrme]

As of FreeBSD 13.2, I believe, ASLR (address space layout randomization; see https://www.freebsd.org/releases/14.0R/relnotes/) is on by default for 64-bit executables. Mostly CCL worked anyway, because we would relocate the saved image when we didn't get the initial IMAGE_BASE_ADDRESS that we wanted from mmap.

We were not relocating the static cons area or the head of the static cons freelist. I think I did the right thing in 23a7158 so that we handle that case now.

There's a way to opt out of the ASLR mitigation, via elfctl(1). We run that now after building the fx86cl64 binary. When ASLR is disabled, we typically don't have to relocate the lisp image.