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@xxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gb@xxxxxxxxxxx --- Comment #19 from Gary Byers <gb@xxxxxxxxxxx> 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review