- Mar 28, 2007
-
-
fgilham authored
-
- Sep 15, 2005
-
-
rtoy authored
.indent.pro.
-
- Mar 18, 2005
-
-
rtoy authored
foreign linkage space. Make it smaller.
-
- Jan 13, 2005
-
-
fgilham authored
lisp.c into the correct <foo>-os.h files.
-
- Jul 08, 2004
-
-
rtoy authored
* purify.c: fixup up fprintf warnings * x86-validate.h: LinkageSpaceStart is an unsigned, so cast it.
-
- Jul 07, 2004
- Jan 16, 2004
- 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.
-
- 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.
-
- Mar 13, 2002
-
-
moore authored
Support for dynamic loading in FreeBSD 4.0 and later. This involves moving the static space up, so a cross-compile is required to bootstrap these changes.
-
- Jan 28, 2002
-
-
pmai authored
was already cleaned up with the OpenBSD port, this doesn't require massive changes. Since current NetBSD is ELF-based by default, we don't make use of the ELF feature, or in other words: The presence of the NetBSD feature implies ELF, since there is no support for non-ELF NetBSD.
-
- Dec 06, 2001
-
-
pmai authored
code which were previously conditionalized on :FreeBSD, are now conditionalized on :BSD instead, with the :BSD feature now implying a 4.4BSD(lite2) derived OS. This should make future BSD-ports easier. FreeBSD and OpenBSD are differentiated by having either :FreeBSD or :OpenBSD on the features list. Currently the OpenBSD port does not have working ELF support, because OpenBSD 2.9 is still non-ELF by default. So don't put ELF on the features list when building for OpenBSD, or fix the code to work correctly in this case instead.
-
- Oct 24, 2000
-
-
dtc authored
of the dynamic space. DYNAMIC_SPACE_SIZE now defines the maximum size, and when defined DEFAULT_DYNAMIC_SPACE_SIZE gives the default. o Increase the maximum dynamic space size for Linux x86 to 1.625GB, with the default remaining at 512MB. o Define the default dynamic space size for FreeBSD x86 to also be 512MB, with a maximum of 2GB.
-
- Sep 16, 1999
-
-
dtc authored
read-only spaces; all the code branches work fine with this map on recent Linux systems.
-
- Nov 13, 1998
-
-
dtc authored
and bringing it closer to the FreeBSD map. From Raymond Toy.
-
- Sep 17, 1998
-
-
dtc authored
address space.
-
- Sep 01, 1998
-
-
dtc authored
-
- Aug 30, 1998
-
-
dtc authored
larger heaps and stacks: * There is now the potential for up to 2.75GB dynamic space on FreeBSD, and 1.75GB on linux. Since GENCGC statically allocates page tables the default size is set at just 1GB. * The Read-only and Static spaces have been increased to 256MB allowing larger heaps to be purified. The Read-only and Static spaces are in the same locations for both the FreeBSD and Linux ports to avoid unnecessary binary incompatibility. * The Control stack and Binking stack now have room for upto 128MB, supporting deeply nested algorithms, and potentially giving room for subdivision for thread stacks. * There is a reserve for the FreeBSD static libraries in the event that the FreeBSD lisp binary is dynamically linked, and the foreign segment size for FreeBSD is now 32MB, up from just 4MB. * There is now significantly more room for C allocated memory, roughly 128M on Linux and 224M on FreeBSD.
-
- May 27, 1998
-
-
dtc authored
cores loaded with subsystems can grow rather large.
-
- May 01, 1998
-
-
dtc authored
support for glibc2.
-
- Dec 17, 1997
-
-
dtc authored
here and it can fill up with a big core.
-
- Nov 25, 1997
-
-
dtc authored
-
- Feb 18, 1997
-
-
dtc authored
-
- Jan 21, 1997
-
-
ram authored
-