Mostly revert 0.9.4.84, since it doesn't compile at all on modern Linux systems (see sbcl-devel message by "Dave" on 2005-09-23): * The decision of whether to use personality() should be completely a run-time property, not a compile-time one. * Change LISP_FEATURE_LINUX cpp conditionals back to LISP_FEATURE_X86 or remove them entirely (this is in linux-os.c, so LISP_FEATURE_LINUX had better be defined; randomization is only enabled on x86 so it's pointless to include the code on other platforms) Additionally: * To solve the problem that 0.9.4.84 was trying to address (no <sys/personality.h> on versions of glibc more than three years old) define the prototype of personality() in linux-os.c. This might not be the optimal solution, but I suppose this isn't the right time to experiment... The syscall itself is old (goes at least back to kernel 2.0), so the system call wrapper should exist even on old versions of libc. There should thus be no problems with linking this code even on ancient systems.
suppressed <sys/personality.h> stuff for old Linux systems (like one of mine) which don't have it (Assuming that I didn't make some weird clerical error, the changes are smaller than they look; I added some extra braces and let emacs regularize the indentation in hopes that it would make it less likely for me to mess up the nesting of if() and #if.)
Don't call alloc_sap before fake_foreign_function_call is run, because this will reset dynamic_space_free_pointer to the original reg_ALLOC value from the signal context, so the next (Lisp-side) allocation will overwrite the SAP object. This may fix Bug #379 (at least partially).
Make VALIDATE-SUPERCLASS obey the rules. ... ah, but we need an additional constraint for CLOS classes to behave: F-S-Cs must have FUNCTION in their CPL, while S-Cs mustn't. Otherwise you end up with things which are functions but whose type-of isn't subtypep function, and similar disasters. ... document this additional constraint.
Declassification of INSTANCE and FUNCALLABLE-INSTANCE. It turns out that the classes INSTANCE and FUNCALLABLE-INSTANCE, as expressed in instance-pointer-lowtag and funcallable-instance-widetag, are incompatible with the MOP's notion of classes: the types INSTANCE and FUNCALLABLE-INSTANCE are necessarily disjoint (no instance can have a widetag of anything other than instance-header-widetag), but FUNCALLABLE-STANDARD-OBJECT is required to be a subclass of STANDARD-OBJECT, and must therefore have the superclasses of STANDARD-OBJECT among its superclasses. If INSTANCE is one of those, FUNCALLABLE-INSTANCE cannot be, so F-S-Os would not be of type FUNCALLABLE-INSTANCE (which is wrong); if it is not one of those, then ordinary S-Os would not be of type INSTANCE (which is wrong). CMUCL, at the time of writing, exhibits type system confusion in this area, as demonstrated by CSR cmucl-imp 2005-09-0x). So, we need to do something else; probably most straightforward to make INSTANCE and FUNCALLABLE-INSTANCE named types, as they are of the same order of specialness as e.g. T -- not quite as special, but almost. Some hacking later... ... the usual type system dance. Play whack-a-mole with test failures and compilation failures until they all go away. Primtype, class, typetran, and so on are fiddled with. ... somewhat hacky code for determining when a class is subtypep instance / funcallable-instance. ... different hard-coded constants for genesis; don't make a special instance-layout, because the instance class is gone. ... just to prove we've achieved something, make STANDARD-OBJECT a superclass of FUNCALLABLE-STANDARD-OBJECT. (Supporting METAOBJECT should be straightforward now) ... many many new tests, both of the before-xc variety (it's amazing in how many ways I can get the type system wrong) and of the regular form. Also add some ctor tests that aren't exercised yet.
a branch target.