[Bug 562226] Review Request: ccl - Free Common Lisp implementation

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=562226

Gary Byers <gb at clozure.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gb at clozure.com

--- Comment #19 from Gary Byers <gb at clozure.com> 2010-12-13 04:27:28 EST ---
Like many CL implementations, CCL compiles and loads executable code into its
heap.  Functions in CL are first-class objects; they can be GCed (just like
strings/arrays/other data structures) or moved around in memory as the GC sees
fit.  The heap (whatever heap functions are allocated in) pretty much has to be
executable for this to work.

Some kinds of functions (lexical closures, see
http://ccl.clozure.com/blog/?p=53 for some of the gory details) can be declared
to have DYNAMIC-EXTENT, which means that their extent (lifetime) is coterminous
with their scope.  Such functions are good candidates for stack-allocation,
which means that whatever stack dynamic-extent closures are allocated on pretty
much has to be executable as well.

Hand-coded functions which provide runtime support for compiled CCL code
(something vaguely analogous to some flavors of libgcc) are accessed via a jump
table at a fixed address.  (Since the functions that call these support
routines - aka "subprimitives" - can move around in memory and can be far from
their targets, PC-relative addressing isn't practical.)

On some platforms, it's possible to use linker scripts (or similar means) to
ensure that the jump table winds up at the expected address; on Linux (at
least), linker scripts tend to break whenever some obscure thing in the C
library changes, and it's therefore necessary to copy the "subprimitive jump
table" from wherever the linker put it to the fixed address that it's expected
to reside at at runtime.  On some architectures, that jump table contains
"branch" or "jump" instructions (that may require their targets to be adjusted
when the instructions are copied) and the copied jump table needs execute
permission.   On x86-64, the jump table just contains absolute 64-bit
addresses, and there's no reason for the copy to have execute permissions; the
error in comment #17 above can be avoided.

If selinux can't deal with the other issues ... well, I was always taught "if
you can't say anything nice about a piece of software, you shouldn't say
anything at all", so I have nothing more to say here.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.