Re: [Sbcl-devel] magic constants

[Perry E. M. <pe...@pi...>]

Christophe Rhodes <cs...@ca...> writes:
> This is likely to be where your problem lies.  These are the deeply
> fragile magic bit.  What happens is that sbcl's native code generator
> is not position independent -- it emits code with hardwired knowledge
> of (at least) static-space-start.  The spaces are mmap()ed with
> overcommit at startup by os_validate / ensure_space, and the implicit
> assumption you're probably falling foul of is that we need to have
> these spaces clear of any interference (by things such as shared
> libraries, the kernel space itself, the C malloc() heap, and so on).

I am starting to understand the principle.

There seem to be six variables that control the various bits here. Can
you explain what they each individually mean?

read-only-space-start
read-only-space-end
static-space-start
static-space-end
dynamic-space-start
dynamic-space-end

> Note the entries for sbcl.core -- it is these entries that correspond
> to the magic numbers in src/compiler/x86/parms.lisp.  In particular,
>   09000000-09001000 rwxp 015d4000 03:06 537673     /usr/lib/sbcl/sbcl.core
>   09001000-29000000 rwxp 00001000 00:00 0
> refer to dynamic space (one page is needed at startup, the rest is
> reserved); if the kernel wishes to put anything else in the middle of
> that range, bad things will happen.

So the dynamic-space-start and dynamic-space-end correspond to
sbcl.core + the rest of the garbage collected allocation region? If
that is correct, What of read-only space and static-space?

Perry