- Mar 23, 2003
-
-
gerd authored
feature :stack-checking because it's not implemented for other systems/architectures yet. It is currently known to work on FreeBSD 4.8-RC/x86 and Debian 2.2.20/x86. * bootfiles/18e/boot3.lisp: New boot file, well, only a description of the boot procedure since no boot file is needed. * lisp/x86-validate.h (SIGNAL_STACK_START, SIGNAL_STACK_SIZE) [__FreeBSD__, __linux__]: New defines. (CONTROL_STACK_SIZE) {__FreeBSD__, __linux__]: Adjust for signal stack. * lisp/validate.c (validate) [RED_ZONE_HIT]: Call os_guard_control_stack. Some cleanup. * lisp/os.h (BOTH_ZONES, YELLOW_ZONE, RED_ZONE): New enums. Add function prototypes. * lisp/interrupt.c (interrupt_install_low_level_handler) [RED_ZONE_HIT]: Deliver protection violations on a dedicated signal stack. * lisp/os-common.c (os_stack_grows_down_1, os_stack_grows_down): New functions. (guard_zones, control_stack_zone, os_guard_control_stack) (os_control_stack_overflow) [RED_ZONE_HIT]: New functions. (os_control_stack_overflow) [!RED_ZONE_HIT]: Dummy function. * lisp/Linux-os.c (sigsegv_handler) [RED_ZONE_HIT]: Handle control stack overflows. * lisp/FreeBSD-os.c: General cleansing. (sigbus_handler) [RED_ZONE_HIT]: Handle control stack overflows. * lisp/FreeBSD-os.h (PROTECTION_VIOLATION_SIGNAL): New define. * lisp/Linux-os.h (PROTECTION_VIOLATION_SIGNAL): New define. * compiler/x86/system.lisp (lisp::%scrub-control-stack): Change defknown from sys:scrub-control-stack. (%scrub-control-stack): Rename VOP. * code/lispinit.lisp (os-guard-control-stack) [#+stack-checking]: Define alien os_guard_control_stack. (%scrub-control-stack) [#+x86]: New function. (scrub-control-stack) [#+x86]: Call %scrub-control-stack, call os-guard-control-stack if #+stack-checking. * code/interr.lisp (yellow-zone-hit, red-zone-hit) [#+stack-checking]: New functions. * code/error.lisp (stack-overflow) [#+stack-checking]: New condition. * compiler/generic/new-genesis.lisp (finish-symbols) [#+stack-checking]: Add symbols for control stack checking. * compiler/x86/parms.lisp (static-symbols): Likewise.
-
- Oct 24, 2002
- Aug 28, 2002
-
-
pmai authored
o Conditionalized some code that is only used in linkage-table builds on :linkage-table and LINKAGE_TABLE respectively. o Modernized undefined_ff_tramp based on recent changes, and renamed it to undefined_foreign_symbol_trap, because it really isn't a trampoline. o Conditionalized a stray puts(...,dlerror()) in Linux-os.c on DEBUG o Installed an error reporter for UNDEFINED_FOREIGN_SYMBOL_ERROR, which for now signals a simple-program-error. We might want to introduced a new condition UNDEFINED-FOREIGN-SYMBOL or something, which could also be used by the old foreign linkage code.
-
- Aug 27, 2002
-
-
moore authored
On x86 FreeBSD and Linux, change the way foreign symbol addresses are resolved. They now go through a table -- effectively a new space in the core file. Function references are resolved lazily, data references are resolved on startup and when a .so is loaded. The end result is that cores can be dumped that contain references to symbols in shared libraries. Also, the dependence of the core on addresses in the Lisp runtime is broken. The linkage table feature is controlled by :linkage-table and LINKAGE_TABLE in C runtime. Several foreign symbols are now Lisp static symbols, so a cross compile is required whether or not the new stuff is used. I've checked in boot4-cross-foreign-linkage.lisp that builds the compiler for linkage table; do whatever you usually do for the non-linkage table case:) Seriously, lets start a discussion on standardizing "cross compilation," not to mention the general build procedure.
-
- Oct 27, 1994
-
-
ram authored
-
- Oct 26, 1994
-
-
ram authored
-
- Oct 25, 1994
-
-
ram authored
genesis anyway.
-
- Oct 24, 1994
-
-
ram authored
-
- Jan 13, 1993
-
-
cvs2git authored
-
- Jul 28, 1992
-
-
wlott authored
-
- Mar 22, 1992
-
-
wlott authored
-
- Mar 02, 1992
-
-
wlott authored
-
- Feb 16, 1992
-
-
wlott authored
region when it should be grown, and vice verca.
-
- May 24, 1991
-
-
wlott authored
-