From: Perry E. M. <pe...@pi...> - 2004-03-27 19:36:12
|
Would it be possible to get the following patches applied to the main source tree? NetBSD support isn't working yet, but most of these are very obvious and it would be nice to keep the number of diffs down to reduce integration issues. These patches are mostly (not all) due to Valtteri Vuorikoski though I made them apply cleanly to the current CVS tree. Index: base-target-features.lisp-expr =================================================================== RCS file: /cvsroot/sbcl/sbcl/base-target-features.lisp-expr,v retrieving revision 1.27 diff -u -r1.27 base-target-features.lisp-expr --- base-target-features.lisp-expr 27 Nov 2003 06:21:04 -0000 1.27 +++ base-target-features.lisp-expr 27 Mar 2004 18:48:46 -0000 @@ -277,6 +277,7 @@ ;; particular version of BSD we're intended to run under.) ;; :freebsd = We're intended to run under FreeBSD. ;; :openbsd = We're intended to run under OpenBSD. + ;; :netbsd = We're intended to run under NetBSD. ;; :sunos = We're intended to run under Solaris user environment ;; with the SunOS kernel. ;; :osf1 = We're intended to run under Tru64 (aka Digital Unix Index: make-config.sh =================================================================== RCS file: /cvsroot/sbcl/sbcl/make-config.sh,v retrieving revision 1.32 diff -u -r1.32 make-config.sh --- make-config.sh 15 Mar 2004 15:24:52 -0000 1.32 +++ make-config.sh 27 Mar 2004 18:48:46 -0000 @@ -129,6 +129,10 @@ sbcl_os="openbsd" ln -s Config.$sbcl_arch-openbsd Config ;; + NetBSD) + printf ' :netbsd' >> $ltf + ln -s Config.$sbcl_arch-netbsd Config + ;; *) echo unsupported BSD variant: `uname` exit 1 Index: src/code/bsd-os.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/bsd-os.lisp,v retrieving revision 1.8 diff -u -r1.8 bsd-os.lisp --- src/code/bsd-os.lisp 29 Jul 2003 13:01:55 -0000 1.8 +++ src/code/bsd-os.lisp 27 Mar 2004 18:48:47 -0000 @@ -17,6 +17,7 @@ (the string ; (to force error in case of unsupported BSD variant) #!+FreeBSD "FreeBSD" #!+OpenBSD "OpenBSD" + #!+NetBSD "NetBSD" #!+Darwin "Darwin")) (defvar *software-version* nil) Index: src/code/foreign.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/foreign.lisp,v retrieving revision 1.19 diff -u -r1.19 foreign.lisp --- src/code/foreign.lisp 22 Nov 2003 02:40:12 -0000 1.19 +++ src/code/foreign.lisp 27 Mar 2004 18:48:47 -0000 @@ -52,7 +52,7 @@ ;;; On any OS where we don't support foreign object file loading, any ;;; query of a foreign symbol value is answered with "no definition ;;; known", i.e. NIL. -#-(or linux sunos FreeBSD OpenBSD darwin) +#-(or linux sunos FreeBSD OpenBSD NetBSD darwin) (defun get-dynamic-foreign-symbol-address (symbol) (declare (type simple-string symbol) (ignore symbol)) nil) @@ -62,7 +62,7 @@ ;;; work on any ELF system with dlopen(3) and dlsym(3) ;;; It also works on OpenBSD, which isn't ELF, but is otherwise modern ;;; enough to have a fairly well working dlopen/dlsym implementation. -#-(or linux sunos FreeBSD OpenBSD darwin) +#-(or linux sunos FreeBSD OpenBSD NetBSD darwin) (macrolet ((define-unsupported-fun (fun-name) `(defun ,fun-name (&rest rest) "unsupported on this system" @@ -70,7 +70,7 @@ (error 'unsupported-operator :name ',fun-name)))) (define-unsupported-fun load-1-foreign) (define-unsupported-fun load-foreign)) -#+(or linux sunos FreeBSD OpenBSD darwin) +#+(or linux sunos FreeBSD OpenBSD NetBSD darwin) (progn ;;; flags for dlopen() Index: src/code/load.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/load.lisp,v retrieving revision 1.33 diff -u -r1.33 load.lisp --- src/code/load.lisp 27 Mar 2004 07:58:16 -0000 1.33 +++ src/code/load.lisp 27 Mar 2004 18:48:48 -0000 @@ -401,7 +401,7 @@ ;;; code for foreign symbol lookup should be here. (defun find-foreign-symbol-in-table (name table) (let ((prefixes - #!+(or osf1 sunos linux freebsd darwin) #("" "ldso_stub__") + #!+(or osf1 sunos linux freebsd netbsd darwin) #("" "ldso_stub__") #!+openbsd #(""))) (declare (notinline some)) ; to suppress bug 117 bogowarning (some (lambda (prefix) Index: src/code/unix.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/unix.lisp,v retrieving revision 1.44 diff -u -r1.44 unix.lisp --- src/code/unix.lisp 30 Dec 2003 21:06:19 -0000 1.44 +++ src/code/unix.lisp 27 Mar 2004 18:48:49 -0000 @@ -293,14 +293,14 @@ ;; a constant. Going the grovel_headers route doesn't seem to be ;; helpful, either, as Solaris doesn't export PATH_MAX from ;; unistd.h. - #!-(or linux openbsd freebsd sunos osf1 darwin) (,stub,) - #!+(or linux openbsd freebsd sunos osf1 darwin) + #!-(or linux openbsd freebsd netbsd sunos osf1 darwin) (,stub,) + #!+(or linux openbsd freebsd netbsd sunos osf1 darwin) (or (newcharstar-string (alien-funcall (extern-alien "getcwd" (function (* char) (* char) size-t)) nil - #!+(or linux openbsd freebsd darwin) 0 + #!+(or linux openbsd freebsd netbsd darwin) 0 #!+(or sunos osf1) 1025)) (simple-perror "getcwd"))) Index: src/runtime/bsd-os.h =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/bsd-os.h,v retrieving revision 1.11 diff -u -r1.11 bsd-os.h --- src/runtime/bsd-os.h 20 Feb 2004 18:15:20 -0000 1.11 +++ src/runtime/bsd-os.h 27 Mar 2004 18:48:50 -0000 @@ -18,7 +18,11 @@ #include <sys/signal.h> typedef caddr_t os_vm_address_t; +#ifdef __NetBSD__ +typedef vsize_t os_vm_size_t; +#else typedef vm_size_t os_vm_size_t; +#endif typedef off_t os_vm_offset_t; typedef int os_vm_prot_t; typedef int os_context_register_t; @@ -28,7 +32,7 @@ * Linux sigaltstack(2) */ typedef struct sigaltstack stack_t; #elif defined __FreeBSD__ -/* FreeBSD 4.6 already has stack_t defined. */ +/* FreeBSD 4.6 and NetBSD 1.6 already have stack_t defined. */ #endif #if defined __FreeBSD__ Index: src/runtime/gencgc.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/gencgc.c,v retrieving revision 1.50 diff -u -r1.50 gencgc.c --- src/runtime/gencgc.c 30 Jan 2004 20:56:06 -0000 1.50 +++ src/runtime/gencgc.c 27 Mar 2004 18:48:54 -0000 @@ -69,7 +69,7 @@ boolean enable_page_protection = 1; /* Should we unmap a page and re-mmap it to have it zero filled? */ -#if defined(__FreeBSD__) || defined(__OpenBSD__) +#if defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) /* comment from cmucl-2.4.8: This can waste a lot of swap on FreeBSD * so don't unmap there. * Index: src/runtime/undefineds.h =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/undefineds.h,v retrieving revision 1.14 diff -u -r1.14 undefineds.h --- src/runtime/undefineds.h 18 Sep 2003 21:09:10 -0000 1.14 +++ src/runtime/undefineds.h 27 Mar 2004 18:48:55 -0000 @@ -38,7 +38,8 @@ #if defined(hpux) \ || defined(SVR4) \ || defined(__FreeBSD__) \ - || defined(__OpenBSD__) + || defined(__OpenBSD__) \ + || defined(__NetBSD__) F(cfgetospeed) F(cfsetospeed) F(cfgetispeed) @@ -152,7 +153,7 @@ #if !defined(SVR4) F(sigsetmask) #endif -#if !defined(SVR4) && !defined(__FreeBSD__) && !defined(__OpenBSD__) +#if !defined(SVR4) && !defined(__FreeBSD__) && !defined(__OpenBSD__) && !defined(__NetBSD__) F(sigstack) F(sigvec) #endif @@ -177,6 +178,7 @@ || defined(SVR4) \ || defined(__FreeBSD__) \ || defined(__OpenBSD__) \ + || defined(__NetBSD__) \ || defined(__linux__) F(tcgetattr) F(tcsetattr) @@ -194,7 +196,8 @@ && !defined(parisc) \ && !defined(SOLARIS) \ && !defined(__OpenBSD__) \ - && !defined(__FreeBSD__) + && !defined(__FreeBSD__) \ + && !defined(__NetBSD__) F(umount) #endif F(unlink) @@ -204,7 +207,7 @@ #ifndef irix F(vfork) #endif -#if !defined(osf1) && !defined(__FreeBSD__) && !defined(__OpenBSD__) +#if !defined(osf1) && !defined(__FreeBSD__) && !defined(__OpenBSD__) && !defined(__NetBSD__) F(vhangup) #endif F(wait) Index: src/runtime/x86-arch.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/x86-arch.c,v retrieving revision 1.23 diff -u -r1.23 x86-arch.c --- src/runtime/x86-arch.c 27 Nov 2003 06:21:04 -0000 1.23 +++ src/runtime/x86-arch.c 27 Mar 2004 18:48:55 -0000 @@ -55,7 +55,7 @@ return &context->uc_mcontext.gregs[16]; #elif defined __FreeBSD__ return &context->uc_mcontext.mc_eflags; -#elif defined __OpenBSD__ +#elif defined __OpenBSD__ || defined __NetBSD__ return &context->sc_eflags; #else #error unsupported OS Index: src/runtime/x86-assem.S =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/x86-assem.S,v retrieving revision 1.13 diff -u -r1.13 x86-assem.S --- src/runtime/x86-assem.S 16 Aug 2003 20:38:40 -0000 1.13 +++ src/runtime/x86-assem.S 27 Mar 2004 18:48:56 -0000 @@ -23,15 +23,15 @@ #include "genesis/thread.h" /* Minimize conditionalization for different OS naming schemes. */ -#if defined __linux__ || defined __FreeBSD__ /* (but *not* OpenBSD) */ +#if defined __linux__ || defined __FreeBSD__ || defined __NetBSD__ /* (but *not* OpenBSD) */ #define GNAME(var) var #else #define GNAME(var) _##var #endif -/* Get the right type of alignment. Linux and FreeBSD (but not OpenBSD) +/* Get the right type of alignment. Linux, FreeBSD and NetBSD (but not OpenBSD) * want alignment in bytes. */ -#if defined(__linux__) || defined(__FreeBSD__) +#if defined(__linux__) || defined(__FreeBSD__) || defined(__NetBSD__) #define align_4byte 4 #define align_8byte 8 #define align_16byte 16 Index: tools-for-build/grovel-headers.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/tools-for-build/grovel-headers.c,v retrieving revision 1.3 diff -u -r1.3 grovel-headers.c --- tools-for-build/grovel-headers.c 6 Dec 2003 16:11:33 -0000 1.3 +++ tools-for-build/grovel-headers.c 27 Mar 2004 18:48:56 -0000 @@ -76,7 +76,7 @@ DEFTYPE("uid-t", uid_t); printf("\n"); - printf(";;; fcntl.h (or unistd.h on OpenBSD)\n"); + printf(";;; fcntl.h (or unistd.h on OpenBSD and NetBSD)\n"); defconstant("r_ok", R_OK); defconstant("w_ok", W_OK); defconstant("x_ok", X_OK); |
From: Perry E. M. <pe...@pi...> - 2004-04-07 01:29:24
|
These patches make sbcl come up successfully under NetBSD 2.0 and above. Note that a number of tests still fail catastrophically (specifically the tests exhaust.impure.lisp foreign.test.sh smoke.impure.lisp in the tests/ directory) but the rest work more or less. There is also the mysterious question of the FPE exception flag I had to disable to make this work. I have no idea why. However, I'd say this is committable right now. Index: src/runtime/Config.x86-netbsd =================================================================== --- /dev/null 2004-04-06 20:12:57.000000000 -0400 +++ src/runtime/Config.x86-netbsd 2004-04-06 20:45:19.000000000 -0400 @@ -0,0 +1,7 @@ +# -*- makefile -*- +include Config.x86-bsd + +ASSEM_SRC += ldso-stubs.S +OS_LINK_FLAGS = -dynamic -export-dynamic + +CFLAGS = -g -Wall -O2 Index: README =================================================================== RCS file: /cvsroot/sbcl/sbcl/README,v retrieving revision 1.4 diff -u -r1.4 README --- README 15 Sep 2003 16:56:13 -0000 1.4 +++ README 7 Apr 2004 00:41:55 -0000 @@ -26,6 +26,10 @@ SYSTEM-SPECIFIC HINTS +for NetBSD: + NetBSD 2.0 and above are required because of the lack of needed + signal APIs in NetBSD 1.6 and earlier. + for OpenBSD: OpenBSD 3.0 has stricter ulimit values, and/or enforces them more strictly, than its predecessors. Therefore SBCL's initial mmap() Index: base-target-features.lisp-expr =================================================================== RCS file: /cvsroot/sbcl/sbcl/base-target-features.lisp-expr,v retrieving revision 1.27 diff -u -r1.27 base-target-features.lisp-expr --- base-target-features.lisp-expr 27 Nov 2003 06:21:04 -0000 1.27 +++ base-target-features.lisp-expr 7 Apr 2004 00:41:56 -0000 @@ -277,6 +277,7 @@ ;; particular version of BSD we're intended to run under.) ;; :freebsd = We're intended to run under FreeBSD. ;; :openbsd = We're intended to run under OpenBSD. + ;; :netbsd = We're intended to run under NetBSD. ;; :sunos = We're intended to run under Solaris user environment ;; with the SunOS kernel. ;; :osf1 = We're intended to run under Tru64 (aka Digital Unix Index: make-config.sh =================================================================== RCS file: /cvsroot/sbcl/sbcl/make-config.sh,v retrieving revision 1.32 diff -u -r1.32 make-config.sh --- make-config.sh 15 Mar 2004 15:24:52 -0000 1.32 +++ make-config.sh 7 Apr 2004 00:41:56 -0000 @@ -129,6 +129,10 @@ sbcl_os="openbsd" ln -s Config.$sbcl_arch-openbsd Config ;; + NetBSD) + printf ' :netbsd' >> $ltf + ln -s Config.$sbcl_arch-netbsd Config + ;; *) echo unsupported BSD variant: `uname` exit 1 Index: doc/sbcl.1 =================================================================== RCS file: /cvsroot/sbcl/sbcl/doc/sbcl.1,v retrieving revision 1.32 diff -u -r1.32 sbcl.1 --- doc/sbcl.1 7 Oct 2003 21:41:27 -0000 1.32 +++ doc/sbcl.1 7 Apr 2004 00:41:57 -0000 @@ -373,7 +373,7 @@ .SH SYSTEM REQUIREMENTS -SBCL currently runs on X86 (Linux, FreeBSD, and OpenBSD), Alpha +SBCL currently runs on X86 (Linux, FreeBSD, OpenBSD, and NetBSD), Alpha (Linux, Tru64), PPC (Linux, Darwin/MacOS X), SPARC (Linux and Solaris 2.x), and MIPS (Linux). For information on other ongoing and possible ports, see the sbcl-devel mailing list, and/or the web site. Index: src/code/bsd-os.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/bsd-os.lisp,v retrieving revision 1.8 diff -u -r1.8 bsd-os.lisp --- src/code/bsd-os.lisp 29 Jul 2003 13:01:55 -0000 1.8 +++ src/code/bsd-os.lisp 7 Apr 2004 00:41:57 -0000 @@ -17,6 +17,7 @@ (the string ; (to force error in case of unsupported BSD variant) #!+FreeBSD "FreeBSD" #!+OpenBSD "OpenBSD" + #!+NetBSD "NetBSD" #!+Darwin "Darwin")) (defvar *software-version* nil) Index: src/code/cold-init.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/cold-init.lisp,v retrieving revision 1.45 diff -u -r1.45 cold-init.lisp --- src/code/cold-init.lisp 5 Apr 2004 23:16:29 -0000 1.45 +++ src/code/cold-init.lisp 7 Apr 2004 00:41:57 -0000 @@ -219,8 +219,10 @@ ;; FIXME: This list of modes should be defined in one place and ;; explicitly shared between here and REINIT. - ;; Why was this marked #!+alpha? CMUCL does it here on all architectures - (set-floating-point-modes :traps '(:overflow :invalid :divide-by-zero)) + ;; FIXME: For some unknown reason, NetBSD/x86 won't run with the + ;; :invalid trap enabled. That should be fixed, but not today... + ;; PEM -- April 5, 2004 + (set-floating-point-modes :traps '(:overflow #!-netbsd :invalid :divide-by-zero)) (show-and-call !class-finalize) @@ -288,7 +290,10 @@ ;; LEAST-NEGATIVE-SINGLE-FLOAT, so the :UNDERFLOW exceptions are ;; disabled by default. Joe User can explicitly enable them if ;; desired. - (set-floating-point-modes :traps '(:overflow :invalid :divide-by-zero)) + ;; FIXME: For some unknown reason, NetBSD/x86 won't run with the + ;; :invalid trap enabled. That should be fixed, but not today... + ;; PEM -- April 5, 2004 + (set-floating-point-modes :traps '(:overflow #!-netbsd :invalid :divide-by-zero)) (sb!thread::maybe-install-futex-functions))) (gc-on) (gc)) Index: src/code/foreign.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/foreign.lisp,v retrieving revision 1.19 diff -u -r1.19 foreign.lisp --- src/code/foreign.lisp 22 Nov 2003 02:40:12 -0000 1.19 +++ src/code/foreign.lisp 7 Apr 2004 00:41:58 -0000 @@ -52,7 +52,7 @@ ;;; On any OS where we don't support foreign object file loading, any ;;; query of a foreign symbol value is answered with "no definition ;;; known", i.e. NIL. -#-(or linux sunos FreeBSD OpenBSD darwin) +#-(or linux sunos FreeBSD OpenBSD NetBSD darwin) (defun get-dynamic-foreign-symbol-address (symbol) (declare (type simple-string symbol) (ignore symbol)) nil) @@ -62,7 +62,7 @@ ;;; work on any ELF system with dlopen(3) and dlsym(3) ;;; It also works on OpenBSD, which isn't ELF, but is otherwise modern ;;; enough to have a fairly well working dlopen/dlsym implementation. -#-(or linux sunos FreeBSD OpenBSD darwin) +#-(or linux sunos FreeBSD OpenBSD NetBSD darwin) (macrolet ((define-unsupported-fun (fun-name) `(defun ,fun-name (&rest rest) "unsupported on this system" @@ -70,7 +70,7 @@ (error 'unsupported-operator :name ',fun-name)))) (define-unsupported-fun load-1-foreign) (define-unsupported-fun load-foreign)) -#+(or linux sunos FreeBSD OpenBSD darwin) +#+(or linux sunos FreeBSD OpenBSD NetBSD darwin) (progn ;;; flags for dlopen() Index: src/code/load.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/load.lisp,v retrieving revision 1.33 diff -u -r1.33 load.lisp --- src/code/load.lisp 27 Mar 2004 07:58:16 -0000 1.33 +++ src/code/load.lisp 7 Apr 2004 00:41:58 -0000 @@ -401,7 +401,7 @@ ;;; code for foreign symbol lookup should be here. (defun find-foreign-symbol-in-table (name table) (let ((prefixes - #!+(or osf1 sunos linux freebsd darwin) #("" "ldso_stub__") + #!+(or osf1 sunos linux freebsd netbsd darwin) #("" "ldso_stub__") #!+openbsd #(""))) (declare (notinline some)) ; to suppress bug 117 bogowarning (some (lambda (prefix) Index: src/code/unix.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/unix.lisp,v retrieving revision 1.44 diff -u -r1.44 unix.lisp --- src/code/unix.lisp 30 Dec 2003 21:06:19 -0000 1.44 +++ src/code/unix.lisp 7 Apr 2004 00:42:00 -0000 @@ -293,14 +293,14 @@ ;; a constant. Going the grovel_headers route doesn't seem to be ;; helpful, either, as Solaris doesn't export PATH_MAX from ;; unistd.h. - #!-(or linux openbsd freebsd sunos osf1 darwin) (,stub,) - #!+(or linux openbsd freebsd sunos osf1 darwin) + #!-(or linux openbsd freebsd netbsd sunos osf1 darwin) (,stub,) + #!+(or linux openbsd freebsd netbsd sunos osf1 darwin) (or (newcharstar-string (alien-funcall (extern-alien "getcwd" (function (* char) (* char) size-t)) nil - #!+(or linux openbsd freebsd darwin) 0 + #!+(or linux openbsd freebsd netbsd darwin) 0 #!+(or sunos osf1) 1025)) (simple-perror "getcwd"))) Index: src/compiler/x86/parms.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/compiler/x86/parms.lisp,v retrieving revision 1.36 diff -u -r1.36 parms.lisp --- src/compiler/x86/parms.lisp 29 Nov 2003 00:35:41 -0000 1.36 +++ src/compiler/x86/parms.lisp 7 Apr 2004 00:42:00 -0000 @@ -135,6 +135,19 @@ ;;; use. (They want to use this address range even if we try to ;;; reserve it with a call to validate() as the first operation in ;;; main().) +;;; * For NetBSD 2.0, the following ranges are used by normal +;;; executables and mmap: +;;; ** Executables are (by default) loaded at 0x08048000. +;;; ** The break for the sbcl runtime seems to end around 0x08400000 +;;; We set read only space around 0x20000000, static +;;; space around 0x30000000, all ending below 0x37fff000 +;;; ** ld.so and other mmap'ed stuff like shared libs start around +;;; 0x48000000 +;;; We set dynamic space between 0x60000000 and 0x98000000 +;;; ** Bottom of the stack is typically not below 0xb0000000 +;;; FYI, this can be looked at with the "pmap" program, and if you +;;; set the top-down mmap allocation option in the kernel (not yet +;;; the default), all bets are totally off! #!+linux (progn @@ -148,7 +161,7 @@ (def!constant dynamic-space-start #x09000000) (def!constant dynamic-space-end #x29000000)) -#!+bsd +#!+(or freebsd openbsd) (progn (def!constant read-only-space-start #x10000000) @@ -163,6 +176,19 @@ #!+freebsd #x48000000 #!+openbsd #x50000000) (def!constant dynamic-space-end #x88000000)) + +#!+netbsd +(progn + + (def!constant read-only-space-start #x20000000) + (def!constant read-only-space-end #x2ffff000) + + (def!constant static-space-start #x30000000) + (def!constant static-space-end #x37fff000) + + (def!constant dynamic-space-start #x60000000) + (def!constant dynamic-space-end #x98000000)) + ;;; Given that NIL is the first thing allocated in static space, we ;;; know its value at compile time: Index: src/runtime/GNUmakefile =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/GNUmakefile,v retrieving revision 1.18 diff -u -r1.18 GNUmakefile --- src/runtime/GNUmakefile 20 Feb 2004 18:15:20 -0000 1.18 +++ src/runtime/GNUmakefile 7 Apr 2004 00:42:00 -0000 @@ -16,7 +16,6 @@ # Config file CFLAGS = -g -Wall -O3 ASFLAGS = $(CFLAGS) -DEPEND_FLAGS = CPPFLAGS = -I. # Some of these things might be Config-dependent in future versions, Index: src/runtime/bsd-os.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/bsd-os.c,v retrieving revision 1.19 diff -u -r1.19 bsd-os.c --- src/runtime/bsd-os.c 20 Feb 2004 18:15:20 -0000 1.19 +++ src/runtime/bsd-os.c 7 Apr 2004 00:42:01 -0000 @@ -21,6 +21,8 @@ #include <stdio.h> #include <sys/param.h> #include <sys/file.h> +#include <unistd.h> +#include <assert.h> #include "sbcl.h" #include "./signal.h" #include "os.h" @@ -37,11 +39,22 @@ #include "validate.h" -vm_size_t os_vm_page_size; +os_vm_size_t os_vm_page_size; +#ifdef __NetBSD__ +#include <sys/resource.h> +#include <string.h> + +static void netbsd_init(); +#endif /* __NetBSD__ */ + void os_init(void) { os_vm_page_size = getpagesize(); + +#ifdef __NetBSD__ + netbsd_init(); +#endif /* __NetBSD__ */ } int *os_context_pc_addr(os_context_t *context) @@ -50,6 +63,8 @@ return CONTEXT_ADDR_FROM_STEM(eip); #elif defined __OpenBSD__ return CONTEXT_ADDR_FROM_STEM(pc); +#elif defined __NetBSD__ + return CONTEXT_ADDR_FROM_STEM(EIP); #elif defined LISP_FEATURE_DARWIN return &context->uc_mcontext->ss.srr0; #else @@ -63,7 +78,7 @@ /* (Unlike most of the other context fields that we access, the * signal mask field is a field of the basic, outermost context * struct itself both in FreeBSD 4.0 and in OpenBSD 2.6.) */ -#if defined __FreeBSD__ || defined LISP_FEATURE_DARWIN +#if defined __FreeBSD__ || __NetBSD__ || defined LISP_FEATURE_DARWIN return &context->uc_sigmask; #elif defined __OpenBSD__ return &context->sc_mask; @@ -162,15 +177,14 @@ { /* The way that we extract low level information like the fault * address is not specified by POSIX. */ -#if defined __FreeBSD__ - void *fault_addr = siginfo->si_addr; -#elif defined __OpenBSD__ +#if defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) void *fault_addr = siginfo->si_addr; #elif defined LISP_FEATURE_DARWIN void *fault_addr = siginfo->si_addr; #else #error unsupported BSD variant #endif + os_context_t *context = arch_os_get_context(&void_context); if (!gencgc_handle_wp_violation(fault_addr)) if(!handle_control_stack_guard_triggered(context,fault_addr)) @@ -213,6 +230,22 @@ } #endif /* defined GENCGC */ + +#ifdef __NetBSD__ +static void netbsd_init() +{ + struct rlimit rl; + + /* NetBSD counts mmap()ed space against the process's data size limit, + * so yank it up. This might be a nasty thing to do? */ + getrlimit (RLIMIT_DATA, &rl); + rl.rlim_cur = 1073741824; + if (setrlimit (RLIMIT_DATA, &rl) < 0) { + fprintf (stderr, "RUNTIME WARNING: unable to raise process data size limit to 1GB (%s). The system may fail to start.\n", + strerror(errno)); + } +} +#endif /* __NetBSD__ */ /* threads */ Index: src/runtime/bsd-os.h =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/bsd-os.h,v retrieving revision 1.11 diff -u -r1.11 bsd-os.h --- src/runtime/bsd-os.h 20 Feb 2004 18:15:20 -0000 1.11 +++ src/runtime/bsd-os.h 7 Apr 2004 00:42:01 -0000 @@ -18,20 +18,26 @@ #include <sys/signal.h> typedef caddr_t os_vm_address_t; +#ifdef __NetBSD__ +typedef vsize_t os_vm_size_t; +#else typedef vm_size_t os_vm_size_t; +#endif typedef off_t os_vm_offset_t; typedef int os_vm_prot_t; typedef int os_context_register_t; -#if defined __OpenBSD__ +#ifdef __OpenBSD__ /* name defined for compatibility between OpenBSD 3.1 sigaltstack(2) and * Linux sigaltstack(2) */ typedef struct sigaltstack stack_t; -#elif defined __FreeBSD__ -/* FreeBSD 4.6 already has stack_t defined. */ #endif +/* FreeBSD 4.6 and NetBSD 1.6 already have stack_t defined. */ + + #if defined __FreeBSD__ + /* Note: The man page for sigaction(2) in FreeBSD 4.0 says that this * is an mcontext_t, but according to comments by Raymond Wiker in the * original FreeBSD port of SBCL, that's wrong, it's actually a @@ -45,9 +51,18 @@ * so we need to implement single stepping in a more roundabout way. */ #define CANNOT_GET_TO_SINGLE_STEP_FLAG #define SIG_MEMORY_FAULT SIGBUS + #elif defined __OpenBSD__ + typedef struct sigcontext os_context_t; #define SIG_MEMORY_FAULT SIGSEGV + +#elif defined __NetBSD__ + +#include <ucontext.h> +typedef ucontext_t os_context_t; +#define SIG_MEMORY_FAULT SIGSEGV + #elif defined LISP_FEATURE_DARWIN /* man pages claim that the third argument is a sigcontext struct, but ucontext_t is defined, matches sigcontext where sensible, @@ -59,6 +74,7 @@ #include <ucontext.h> typedef ucontext_t os_context_t; #define SIG_MEMORY_FAULT SIGBUS + #else #error unsupported BSD variant #endif Index: src/runtime/gencgc.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/gencgc.c,v retrieving revision 1.52 diff -u -r1.52 gencgc.c --- src/runtime/gencgc.c 5 Apr 2004 23:39:14 -0000 1.52 +++ src/runtime/gencgc.c 7 Apr 2004 00:42:04 -0000 @@ -244,7 +248,9 @@ * seized before all accesses to generations[] or to parts of * page_table[] that other threads may want to see */ +#ifdef LISP_FEATURE_SB_THREAD static lispobj free_pages_lock=0; +#endif /* @@ -495,7 +504,9 @@ gc_assert((alloc_region->first_page == 0) && (alloc_region->last_page == -1) && (alloc_region->free_pointer == alloc_region->end_addr)); +#ifdef LISP_FEATURE_SB_THREAD get_spinlock(&free_pages_lock,(int) alloc_region); +#endif if (unboxed) { first_page = generations[gc_alloc_generation].alloc_unboxed_start_page; @@ -557,7 +568,9 @@ (lispobj)(((char *)heap_base) + last_free_page*PAGE_BYTES), 0); } +#ifdef LISP_FEATURE_SB_THREAD release_spinlock(&free_pages_lock); +#endif /* we can do this after releasing free_pages_lock */ if (gencgc_zero_check) { @@ -694,7 +707,9 @@ next_page = first_page+1; +#ifdef LISP_FEATURE_SB_THREAD get_spinlock(&free_pages_lock,(int) alloc_region); +#endif if (alloc_region->free_pointer != alloc_region->start_addr) { /* some bytes were allocated in the region */ orig_first_page_bytes_used = page_table[first_page].bytes_used; @@ -798,7 +813,9 @@ page_table[next_page].allocated = FREE_PAGE_FLAG; next_page++; } +#ifdef LISP_FEATURE_SB_THREAD release_spinlock(&free_pages_lock); +#endif /* alloc_region is per-thread, we're ok to do this unlocked */ gc_set_region_empty(alloc_region); } @@ -817,7 +834,9 @@ int bytes_used; int next_page; +#ifdef LISP_FEATURE_SB_THREAD get_spinlock(&free_pages_lock,(int) alloc_region); +#endif if (unboxed) { first_page = @@ -918,7 +937,9 @@ SetSymbolValue(ALLOCATION_POINTER, (lispobj)(((char *)heap_base) + last_free_page*PAGE_BYTES),0); } +#ifdef LISP_FEATURE_SB_THREAD release_spinlock(&free_pages_lock); +#endif return((void *)(page_address(first_page)+orig_first_page_bytes_used)); } @@ -933,7 +954,9 @@ int bytes_found; int num_pages; int large_p=(nbytes>=large_object_size); +#ifdef LISP_FEATURE_SB_THREAD gc_assert(free_pages_lock); +#endif /* Search for a contiguous free space of at least nbytes. If it's * a large object then align it on a page boundary by searching @@ -1667,7 +1690,8 @@ return copy_large_object(object, length); } - +/* FIXME: Not obviously used anywhere... */ +#ifdef REMOVEME static lispobj trans_unboxed_large(lispobj object) { @@ -1683,6 +1707,7 @@ return copy_large_unboxed_object(object, length); } +#endif /* Index: src/runtime/interrupt.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/interrupt.c,v retrieving revision 1.57 diff -u -r1.57 interrupt.c --- src/runtime/interrupt.c 30 Mar 2004 12:24:53 -0000 1.57 +++ src/runtime/interrupt.c 7 Apr 2004 00:42:05 -0000 @@ -730,7 +730,7 @@ } #ifndef LISP_FEATURE_GENCGC -/* This function gets called from the SIGSEGV (for e.g. Linux or +/* This function gets called from the SIGSEGV (for e.g. Linux, NetBSD, & * OpenBSD) or SIGBUS (for e.g. FreeBSD) handler. Here we check * whether the signal was due to treading on the mprotect()ed zone - * and if so, arrange for a GC to happen. */ Index: src/runtime/thread.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/thread.c,v retrieving revision 1.25 diff -u -r1.25 thread.c --- src/runtime/thread.c 30 Mar 2004 12:24:53 -0000 1.25 +++ src/runtime/thread.c 7 Apr 2004 00:42:14 -0000 @@ -24,7 +24,7 @@ void get_spinlock(lispobj *word,int value); -int +static int initial_thread_trampoline(struct thread *th) { lispobj function; @@ -35,13 +35,14 @@ if(th->pid < 1) lose("th->pid not set up right"); th->state=STATE_RUNNING; -#if defined(LISP_FEATURE_X86) +#ifdef LISP_FEATURE_X86 return call_into_lisp_first_time(function,args,0); #else return funcall0(function); #endif } +#ifdef LISP_FEATURE_LINUX /* this is the first thing that clone() runs in the child (which is * why the silly calling convention). Basically it calls the user's * requested lisp function after doing arch_os_thread_init and @@ -62,6 +63,7 @@ th->state=STATE_RUNNING; return funcall0(function); } +#endif /* LISP_FEATURE_LINUX */ /* this is called from any other thread to create the new one, and * initialize all parts of it that can be initialized from another @@ -117,9 +119,9 @@ #ifdef LISP_FEATURE_X86 STATIC_TLS_INIT(PSEUDO_ATOMIC_ATOMIC,pseudo_atomic_atomic); STATIC_TLS_INIT(PSEUDO_ATOMIC_INTERRUPTED,pseudo_atomic_interrupted); -#endif +#endif /* LISP_FEATURE_X86 */ #undef STATIC_TLS_INIT -#endif +#endif /* LISP_FEATURE_SB_THREAD */ } th->control_stack_start = spaces; @@ -191,16 +193,21 @@ return 0; } -void link_thread(struct thread *th,pid_t kid_pid) +static void +link_thread(struct thread *th,pid_t kid_pid) { +#ifdef LISP_FEATURE_SB_THREAD get_spinlock(&all_threads_lock,kid_pid); +#endif th->next=all_threads; all_threads=th; /* note that th->pid is 0 at this time. We rely on all_threads_lock * to ensure that we don't have >1 thread with pid=0 on the list at once */ protect_control_stack_guard_page(th->pid,1); +#ifdef LISP_FEATURE_SB_THREAD release_spinlock(&all_threads_lock); +#endif th->pid=kid_pid; /* child will not start until this is set */ } @@ -229,7 +236,7 @@ return 0; } } -#endif +#endif /* LISP_FEATURE_LINUX */ void destroy_thread (struct thread *th) { @@ -238,7 +245,9 @@ #ifdef LISP_FEATURE_GENCGC gc_alloc_update_page_tables(0, &th->alloc_region); #endif +#ifdef LISP_FEATURE_SB_THREAD get_spinlock(&all_threads_lock,th->pid); +#endif th->state=STATE_STOPPED; if(th==all_threads) all_threads=th->next; @@ -247,7 +256,9 @@ while(th1 && th1->next!=th) th1=th1->next; if(th1) th1->next=th->next; /* unlink */ } +#ifdef LISP_FEATURE_SB_THREAD release_spinlock(&all_threads_lock); +#endif if(th && th->tls_cookie>=0) arch_os_thread_cleanup(th); os_invalidate((os_vm_address_t) th->control_stack_start, ((sizeof (lispobj)) @@ -268,7 +279,7 @@ /* These are not needed unless #+SB-THREAD, and since sigwaitinfo() * doesn't seem to be easily available everywhere (OpenBSD...) it's * more trouble than it's worth to compile it when not needed. */ -#if defined LISP_FEATURE_SB_THREAD +#ifdef LISP_FEATURE_SB_THREAD void block_sigcont(void) { /* don't allow ourselves to receive SIGCONT while we're in the @@ -352,4 +363,4 @@ } release_spinlock(&all_threads_lock); } -#endif +#endif /* LISP_FEATURE_SB_THREAD */ Index: src/runtime/thread.h =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/thread.h,v retrieving revision 1.9 diff -u -r1.9 thread.h --- src/runtime/thread.h 6 Oct 2003 16:48:39 -0000 1.9 +++ src/runtime/thread.h 7 Apr 2004 00:42:14 -0000 @@ -104,7 +104,7 @@ * much stuff like struct thread and all_threads to be defined, which * usually aren't by that time. So, it's here instead. Sorry */ -inline static struct thread *arch_os_get_current_thread() { +static inline struct thread *arch_os_get_current_thread() { #if defined(LISP_FEATURE_SB_THREAD) && defined (LISP_FEATURE_X86) register struct thread *me=0; if(all_threads) Index: src/runtime/undefineds.h =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/undefineds.h,v retrieving revision 1.14 diff -u -r1.14 undefineds.h --- src/runtime/undefineds.h 18 Sep 2003 21:09:10 -0000 1.14 +++ src/runtime/undefineds.h 7 Apr 2004 00:42:15 -0000 @@ -38,7 +38,8 @@ #if defined(hpux) \ || defined(SVR4) \ || defined(__FreeBSD__) \ - || defined(__OpenBSD__) + || defined(__OpenBSD__) \ + || defined(__NetBSD__) F(cfgetospeed) F(cfsetospeed) F(cfgetispeed) @@ -152,7 +153,7 @@ #if !defined(SVR4) F(sigsetmask) #endif -#if !defined(SVR4) && !defined(__FreeBSD__) && !defined(__OpenBSD__) +#if !defined(SVR4) && !defined(__FreeBSD__) && !defined(__OpenBSD__) && !defined(__NetBSD__) F(sigstack) F(sigvec) #endif @@ -177,6 +178,7 @@ || defined(SVR4) \ || defined(__FreeBSD__) \ || defined(__OpenBSD__) \ + || defined(__NetBSD__) \ || defined(__linux__) F(tcgetattr) F(tcsetattr) @@ -194,7 +196,8 @@ && !defined(parisc) \ && !defined(SOLARIS) \ && !defined(__OpenBSD__) \ - && !defined(__FreeBSD__) + && !defined(__FreeBSD__) \ + && !defined(__NetBSD__) F(umount) #endif F(unlink) @@ -204,7 +207,7 @@ #ifndef irix F(vfork) #endif -#if !defined(osf1) && !defined(__FreeBSD__) && !defined(__OpenBSD__) +#if !defined(osf1) && !defined(__FreeBSD__) && !defined(__OpenBSD__) && !defined(__NetBSD__) F(vhangup) #endif F(wait) @@ -254,6 +257,7 @@ F(gethostbyaddr) /* other miscellaneous things */ +/* FIXME: NetBSD needs to get fixed here too PEM 2004-03-27 */ #if defined(SVR4) || defined(__FreeBSD__) F(setpgid) F(getpgid) Index: src/runtime/x86-arch.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/x86-arch.c,v retrieving revision 1.23 diff -u -r1.23 x86-arch.c --- src/runtime/x86-arch.c 27 Nov 2003 06:21:04 -0000 1.23 +++ src/runtime/x86-arch.c 7 Apr 2004 00:42:15 -0000 @@ -57,6 +57,8 @@ return &context->uc_mcontext.mc_eflags; #elif defined __OpenBSD__ return &context->sc_eflags; +#elif defined __NetBSD__ + return &(context->uc_mcontext.__gregs[_REG_EFL]); #else #error unsupported OS #endif Index: src/runtime/x86-assem.S =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/x86-assem.S,v retrieving revision 1.14 diff -u -r1.14 x86-assem.S --- src/runtime/x86-assem.S 5 Apr 2004 23:39:14 -0000 1.14 +++ src/runtime/x86-assem.S 7 Apr 2004 00:42:16 -0000 @@ -23,15 +23,15 @@ #include "genesis/thread.h" /* Minimize conditionalization for different OS naming schemes. */ -#if defined __linux__ || defined __FreeBSD__ /* (but *not* OpenBSD) */ +#if defined __linux__ || defined __FreeBSD__ || defined __NetBSD__ /* (but *not* OpenBSD) */ #define GNAME(var) var #else #define GNAME(var) _##var #endif -/* Get the right type of alignment. Linux and FreeBSD (but not OpenBSD) +/* Get the right type of alignment. Linux, FreeBSD and NetBSD (but not OpenBSD) * want alignment in bytes. */ -#if defined(__linux__) || defined(__FreeBSD__) +#if defined(__linux__) || defined(__FreeBSD__) || defined(__NetBSD__) #define align_4byte 4 #define align_8byte 8 #define align_16byte 16 Index: src/runtime/x86-bsd-os.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/x86-bsd-os.c,v retrieving revision 1.3 diff -u -r1.3 x86-bsd-os.c --- src/runtime/x86-bsd-os.c 19 Sep 2003 15:25:53 -0000 1.3 +++ src/runtime/x86-bsd-os.c 7 Apr 2004 00:42:16 -0000 @@ -12,7 +12,8 @@ * flavour, with the cross-architecture complications that this * entails; unfortunately, currently the situation is worse, not * better, than in the above paragraph. */ - + +#if defined(__FreeBSD__) || defined(__OpenBSD__) int * os_context_register_addr(os_context_t *context, int offset) { @@ -43,6 +44,43 @@ { return CONTEXT_ADDR_FROM_STEM(esp); } + +#endif /* __FreeBSD__ || __OpenBSD__ */ + +#ifdef __NetBSD__ +int * +os_context_register_addr(os_context_t *context, int offset) +{ + switch(offset) { + case 0: + return CONTEXT_ADDR_FROM_STEM(EAX); + case 2: + return CONTEXT_ADDR_FROM_STEM(ECX); + case 4: + return CONTEXT_ADDR_FROM_STEM(EDX); + case 6: + return CONTEXT_ADDR_FROM_STEM(EBX); + case 8: + return CONTEXT_ADDR_FROM_STEM(ESP); + case 10: + return CONTEXT_ADDR_FROM_STEM(EBP); + case 12: + return CONTEXT_ADDR_FROM_STEM(ESI); + case 14: + return CONTEXT_ADDR_FROM_STEM(EDI); + default: + return 0; + } +} + +int * +os_context_sp_addr(os_context_t *context) +{ + return &(_UC_MACHINE_SP(context)); +} + +#endif /* __NetBSD__ */ + /* FIXME: If this can be a no-op on BSD/x86, then it Index: src/runtime/x86-bsd-os.h =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/x86-bsd-os.h,v retrieving revision 1.3 diff -u -r1.3 x86-bsd-os.h --- src/runtime/x86-bsd-os.h 29 Jul 2003 13:01:56 -0000 1.3 +++ src/runtime/x86-bsd-os.h 7 Apr 2004 00:42:16 -0000 @@ -13,6 +13,8 @@ #define CONTEXT_ADDR_FROM_STEM(stem) &context->uc_mcontext.mc_ ## stem #elif defined __OpenBSD__ #define CONTEXT_ADDR_FROM_STEM(stem) &context->sc_ ## stem +#elif defined __NetBSD__ +#define CONTEXT_ADDR_FROM_STEM(stem) &((context)->uc_mcontext.__gregs[_REG_ ## stem]) #else #error unsupported BSD variant #endif Index: tools-for-build/grovel-headers.c =================================================================== RCS file: /cvsroot/sbcl/sbcl/tools-for-build/grovel-headers.c,v retrieving revision 1.4 diff -u -r1.4 grovel-headers.c --- tools-for-build/grovel-headers.c 5 Apr 2004 23:16:36 -0000 1.4 +++ tools-for-build/grovel-headers.c 7 Apr 2004 00:42:16 -0000 @@ -76,7 +76,7 @@ DEFTYPE("uid-t", uid_t); printf("\n"); - printf(";;; fcntl.h (or unistd.h on OpenBSD)\n"); + printf(";;; fcntl.h (or unistd.h on OpenBSD and NetBSD)\n"); defconstant("r_ok", R_OK); defconstant("w_ok", W_OK); defconstant("x_ok", X_OK); |
From: Christophe R. <cs...@ca...> - 2004-04-08 12:22:52
|
"Perry E. Metzger" <pe...@pi...> writes: > These patches make sbcl come up successfully under NetBSD 2.0 and above. I've committed most of this to the NetBSD branch (-r netbsd_branch). Could you check that that branch builds for you on NetBSD? There remain one or two things to get done before merging on to HEAD: firstly, > +for NetBSD: > + NetBSD 2.0 and above are required because of the lack of needed > + signal APIs in NetBSD 1.6 and earlier. Can you enforce this by a uname() check in netbsd_init()? It would be good to give the user as informative an error message as possible. > + /* NetBSD counts mmap()ed space against the process's data size limit, > + * so yank it up. This might be a nasty thing to do? */ > + getrlimit (RLIMIT_DATA, &rl); > + rl.rlim_cur = 1073741824; What is this number? I mean apart from 0x40000000... :-) Is it calculated from somewhere, or just SOMETHING_BIG? > +#ifdef LISP_FEATURE_SB_THREAD > static lispobj free_pages_lock=0; > +#endif I haven't merged this (and similar), because I'm fairly sure the right answer is to define a null version in x86-arch.h for non-threaded builds, leaving the logic in the main body of the code untouched. If the presence of our spinlock implementation is causing you a problem on NetBSD, adding definitions static inline void get_spinlock(lispobj *word, int value) { *word = value; } static inline void get_spinlock(lispobj *word, int value) { *word = 0; } or similar, conditional on ! LISP_FEATURE_SB_THREAD, is probably the way to go. > /* other miscellaneous things */ > +/* FIXME: NetBSD needs to get fixed here too PEM 2004-03-27 */ > #if defined(SVR4) || defined(__FreeBSD__) > F(setpgid) > F(getpgid) What does this comment mean? Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Perry E. M. <pe...@pi...> - 2004-04-08 12:50:48
|
Christophe Rhodes <cs...@ca...> writes: > "Perry E. Metzger" <pe...@pi...> writes: > >> These patches make sbcl come up successfully under NetBSD 2.0 and above. > > I've committed most of this to the NetBSD branch (-r netbsd_branch). > Could you check that that branch builds for you on NetBSD? I checked that my patches built cleanly against a fresh checkout of the head (my tree is not the same as that in the patches...) If you pull up to the head, I'll fix anything that is still broken there promptly -- there won't be a release claiming to work on NetBSD that does not. > There remain one or two things to get done before merging on to HEAD: > firstly, > >> +for NetBSD: >> + NetBSD 2.0 and above are required because of the lack of needed >> + signal APIs in NetBSD 1.6 and earlier. > > Can you enforce this by a uname() check in netbsd_init()? It would be > good to give the user as informative an error message as possible. Actually, the right thing to do is to error out on a particular __NetBSD_Version__ -- I'll do it. >> + /* NetBSD counts mmap()ed space against the process's data size limit, >> + * so yank it up. This might be a nasty thing to do? */ >> + getrlimit (RLIMIT_DATA, &rl); >> + rl.rlim_cur = 1073741824; > > What is this number? I mean apart from 0x40000000... :-) Is it > calculated from somewhere, or just SOMETHING_BIG? I got that code straight from the last guy to play the NetBSD port game. I'm actually unsure about how needed it is, but unfortunately it is hard for me to know given the way my machines are set up... (long story.) >> +#ifdef LISP_FEATURE_SB_THREAD >> static lispobj free_pages_lock=0; >> +#endif > > I haven't merged this (and similar), because I'm fairly sure the right > answer is to define a null version in x86-arch.h for non-threaded > builds, leaving the logic in the main body of the code untouched. I'm not sure about that. I think, among other things, it is less confusing to have a reader see that spin lock code is obviously only in use when needed. However, it isn't my call to make. > If the presence of our spinlock implementation is causing you a > problem on NetBSD, It caused substantial trouble during debugging, and it certainly isn't correct to have it there in a non-threaded version (you end up locking the bus unnecessarily all over the place...) > adding definitions > static inline void get_spinlock(lispobj *word, int value) { > *word = value; } > static inline void get_spinlock(lispobj *word, int value) { > *word = 0; } > or similar, conditional on ! LISP_FEATURE_SB_THREAD, is probably the > way to go. Why the *word = 0? Why not just empty? > >> /* other miscellaneous things */ >> +/* FIXME: NetBSD needs to get fixed here too PEM 2004-03-27 */ >> #if defined(SVR4) || defined(__FreeBSD__) >> F(setpgid) >> F(getpgid) > > What does this comment mean? NetBSD can't just be ifdefed in there because some of what follows has been treated with the __rename trick in the NetBSD sources, but properly speaking NetBSD should be getting treatment like FreeBSD there to make the same calls available. The proper solution isn't obvious and it was a note to me to rototill the way that whole file works to make it work correctly on more platforms. (FYI, it has some serious problems as it stands on many platforms, but that's a long long story...) Perry |
From: Christophe R. <cs...@ca...> - 2004-04-08 14:06:37
|
"Perry E. Metzger" <pe...@pi...> writes: > I checked that my patches built cleanly against a fresh checkout of > the head (my tree is not the same as that in the patches...) > > If you pull up to the head, I'll fix anything that is still broken > there promptly -- there won't be a release claiming to work on NetBSD > that does not. OK. Go wild. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Christophe R. <cs...@ca...> - 2004-04-08 13:20:16
|
"Perry E. Metzger" <pe...@pi...> writes: >> Can you enforce this by a uname() check in netbsd_init()? It would be >> good to give the user as informative an error message as possible. > > Actually, the right thing to do is to error out on a particular > __NetBSD_Version__ -- I'll do it. Sorry, why is this the right thing? If that's a preprocessor symbol, it doesn't seem right to assume that code built on a system with the right signals behaviour will run on a system without -- the check needs to be performed at runtime. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Perry E. M. <pe...@pi...> - 2004-04-08 15:06:00
|
Christophe Rhodes <cs...@ca...> writes: >>> Can you enforce this by a uname() check in netbsd_init()? It would be >>> good to give the user as informative an error message as possible. >> >> Actually, the right thing to do is to error out on a particular >> __NetBSD_Version__ -- I'll do it. > > Sorry, why is this the right thing? If that's a preprocessor symbol, > it doesn't seem right to assume that code built on a system with the > right signals behaviour will run on a system without -- the check > needs to be performed at runtime. Ah, you are correct there. Although it is unlikely one could manage to try to run the code on another box (it would die near instantly) one might try and it would be reasonable to prevent it. On the other hand, uname isn't right either, sysctl(3) is... Perry |
From: Valtteri V. <vu...@pu...> - 2004-04-16 15:53:39
|
"Perry E. Metzger" <pe...@pi...> writes: > > What is this number? I mean apart from 0x40000000... :-) Is it > > calculated from somewhere, or just SOMETHING_BIG? > > I got that code straight from the last guy to play the NetBSD port > game. I'm actually unsure about how needed it is, but unfortunately it > is hard for me to know given the way my machines are set up... (long > story.) This is just something big. ISTR this was needed at some time to do the mmap() for large pieces of memory which is done somewhere in the init code. If sbcl starts at all with this code removed, it should be safe to remove. -v |
From: Perry E. M. <pe...@pi...> - 2004-04-16 16:34:35
|
Valtteri Vuorikoski <vu...@pu...> writes: > "Perry E. Metzger" <pe...@pi...> writes: >> > What is this number? I mean apart from 0x40000000... :-) Is it >> > calculated from somewhere, or just SOMETHING_BIG? >> >> I got that code straight from the last guy to play the NetBSD port >> game. I'm actually unsure about how needed it is, but unfortunately it >> is hard for me to know given the way my machines are set up... (long >> story.) > > This is just something big. ISTR this was needed at some time to do > the mmap() for large pieces of memory which is done somewhere in the > init code. If sbcl starts at all with this code removed, it should > be safe to remove. Not necessarily. It would start on my machine regardless because I have my rlimits set through the roof. Perry |
From: Valtteri V. <vu...@pu...> - 2004-04-16 17:41:12
|
"Perry E. Metzger" <pe...@pi...> writes: > Not necessarily. It would start on my machine regardless because I > have my rlimits set through the roof. hmm, good point. Make that "assuming you are using default rlimits". -v |
From: Christophe R. <cs...@ca...> - 2004-03-29 10:50:19
|
"Perry E. Metzger" <pe...@pi...> writes: > Would it be possible to get the following patches applied to the main > source tree? NetBSD support isn't working yet, but most of these are > very obvious and it would be nice to keep the number of diffs down to > reduce integration issues. > > These patches are mostly (not all) due to Valtteri Vuorikoski though I > made them apply cleanly to the current CVS tree. Thank you. I've merged these into version 0.8.9.6.netbsd.1, which is accessible in the CVS branch with tag netbsd_branch. (To be sure of tracking that branch, use a command like "cvs update -r netbsd_branch"). I hope that suits, Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Perry E. M. <pe...@pi...> - 2004-03-29 16:01:37
|
Christophe Rhodes <cs...@ca...> writes: >> Would it be possible to get the following patches applied to the main >> source tree? NetBSD support isn't working yet, but most of these are >> very obvious and it would be nice to keep the number of diffs down to >> reduce integration issues. >> >> These patches are mostly (not all) due to Valtteri Vuorikoski though I >> made them apply cleanly to the current CVS tree. > > Thank you. I've merged these into version 0.8.9.6.netbsd.1, which is > accessible in the CVS branch with tag netbsd_branch. (To be sure of > tracking that branch, use a command like "cvs update -r netbsd_branch"). > > I hope that suits, Thanks for doing the integration. I'd sort of imagined these could go into the mainline, though -- I was very careful to strip out all the substantive patches and just update the various files that were absolutely safe to update. FYI, I have a lot more patches, some of them MI. I also have been working to reduce the number of warnings produced by the C compiler when building the run time... Perry |
From: Christophe R. <cs...@ca...> - 2004-03-29 16:42:42
|
"Perry E. Metzger" <pe...@pi...> writes: > Christophe Rhodes <cs...@ca...> writes: >> Thank you. I've merged these into version 0.8.9.6.netbsd.1, which is >> accessible in the CVS branch with tag netbsd_branch. (To be sure of >> tracking that branch, use a command like "cvs update -r netbsd_branch"). >> >> I hope that suits, > > Thanks for doing the integration. I'd sort of imagined these could go > into the mainline, though -- I was very careful to strip out all the > substantive patches and just update the various files that were > absolutely safe to update. Does this affect the way you'd work on the NetBSD port in a substantial way? I quite agree with you that the patches that I merged were safe and uncontroversial, but on the other hand they were also advertising functionality which isn't there at the moment, absent the rest of the port. If there's a compelling reason for them to track the mainline, then that can probably be arranged, but I'd have thought that it would be easier for you, too, to track from a solid base and then integrate at the end. But maybe not? > FYI, I have a lot more patches, some of them MI. I also have been > working to reduce the number of warnings produced by the C compiler > when building the run time... I don't know what "MI" means here, I'm afraid. Warning-reducing patches would tend to get directly applied to HEAD, given that their functionality is directly applicable and immediately testable -- in a way that adding :netbsd to the list of possible features isn't really. I can be flexible on this; I'm aware that CVS isn't the most adaptable of tools, and consequently that human adaptability is needed to compensate. In my worldview, a mainline patch is a relatively self-contained chunk adding functionality or fixing bugs; on the other hand, it's not dogma (it's just easier for me to keep track of things, that's all). If you want a bright side, it makes it easier for me to apply cumulative patches to the netbsd branch after light review, because I know I won't break things for anyone else; it's also a magic "ignore code freeze period" card, which might be helpful :-) Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Perry E. M. <pe...@pi...> - 2004-03-29 18:35:15
|
Christophe Rhodes <cs...@ca...> writes: >> Thanks for doing the integration. I'd sort of imagined these could go >> into the mainline, though -- I was very careful to strip out all the >> substantive patches and just update the various files that were >> absolutely safe to update. > > Does this affect the way you'd work on the NetBSD port in a > substantial way? Somewhat. I'm trying to track the head of the CVS tree in doing the work -- I won't be checking out the branch so I can avoid integration issues later on. > I quite agree with you that the patches that I merged were safe and > uncontroversial, but on the other hand they were also advertising > functionality which isn't there at the moment, absent the rest of > the port. Well, I didn't submit my documentation fixes, so users reading the docs won't see the changes... >> FYI, I have a lot more patches, some of them MI. I also have been >> working to reduce the number of warnings produced by the C compiler >> when building the run time... > > I don't know what "MI" means here, Machine independent, as opposed to "MD", machine dependent. I'm used to that jargon in other projects, though I suppose it isn't the lingo around here. -- Perry E. Metzger pe...@pi... |
From: Nikodemus S. <tsi...@cc...> - 2004-03-29 19:26:52
|
On Mon, 29 Mar 2004, Perry E. Metzger wrote: > Somewhat. I'm trying to track the head of the CVS tree in doing the > work -- I won't be checking out the branch so I can avoid integration > issues later on. This is a bit tangential, but... Have you considered a local repository and importing the HEAD as a vendor branch on eg. weekly basis, and then merging it into your own (local) branch? It may not be as convenient as Arch, but still having trouble with the latter I've found this a relatively troublefree way of maintaining local changes. The following snippet gives you the CVS line to import the current HEAD with an appropriate tag: echo ' cvs -d ~/cvsroot import -m "Merged from anoncvs" sbcl official SBCL_'\ `sbcl --noinform --noprint --userinit /dev/null <<EOF (write-line (with-open-file (f "version.lisp-expr") (substitute #\\_ #\\. (read f)))) EOF` Then doing cvs up -jSBCL_(version) in your local branch merges that in. Just a thought. ;) Cheers, -- Nikodemus |
From: Perry E. M. <pe...@pi...> - 2004-03-29 21:58:14
|
Nikodemus Siivola <tsi...@cc...> writes: > This is a bit tangential, but... > > Have you considered a local repository and importing the HEAD as a vendor > branch on eg. weekly basis, and then merging it into your own (local) > branch? That would make a lot of sense except that the changes I'm doing are pretty small -- this is more of a "knowing where to hit the thing with the hammer" type of job than anything. Right now I'm stuck on an apparent NetBSD kernel bug, actually. -- Perry E. Metzger pe...@pi... |
From: Christophe R. <cs...@ca...> - 2004-03-29 19:48:04
|
"Perry E. Metzger" <pe...@pi...> writes: > Christophe Rhodes <cs...@ca...> writes: >>> Thanks for doing the integration. I'd sort of imagined these could go >>> into the mainline, though -- I was very careful to strip out all the >>> substantive patches and just update the various files that were >>> absolutely safe to update. >> >> Does this affect the way you'd work on the NetBSD port in a >> substantial way? > > Somewhat. I'm trying to track the head of the CVS tree in doing the > work -- I won't be checking out the branch so I can avoid integration > issues later on. I don't suppose I can ask you to work on the branch, and then let me deal with the integration issues? The reason it's likely to be easier is that once you're satisfied with the NetBSD work, users of other platforms can test the accumulated changes once, make sure everything still works, and then we can merge the patch (obtainable by diffing the head of netbsd_branch with the branch point) onto HEAD in one go. This means that firstly we only have to deal with conflicts once, rather than every time someone else touches any given bit of code; secondly, we don't have to test on our rather large numbers of platforms each time you touch code that is shared in a non-trivial way; thirdly, and probably most importantly, until the NetBSD port works at least to the point of getting to the first prompt any patches dealing with NetBSD functionality are speculative and untestable, at least from my point of view. >>> FYI, I have a lot more patches, some of them MI. I also have been >>> working to reduce the number of warnings produced by the C compiler >>> when building the run time... >> >> I don't know what "MI" means here, > > Machine independent, as opposed to "MD", machine dependent. I'm used > to that jargon in other projects, though I suppose it isn't the lingo > around here. Thanks. Machine-independent patches, similarly to warnings-obliterating patches, will tend to be committed to HEAD directly. If this is awful for you (because you only have one tree where you have both sets of patches, say), I'd be only moderately unhappy to apply them to the branch instead (treating it conceptually as perry_metzger_branch rather than netbsd_branch, if you see what I mean), but if you're extracting them as individual patches, then once they're in HEAD you can 'reverse apply' them to your branch tree, and then they'll disappear from view. Another possibility, if it suits you better, is to apply the machine-independent parts to HEAD now, and start a new netbsd_branch. One way of making me feel happier about applying effectively-untestable patches to CVS HEAD is to give some kind of an indication of timeframe; if it's clear to you that all of the integration issues and functionality will be ready in three weeks' time or thereabouts, then some of my worries disappear, because the changes will be effectively testable by the time our next release period occurs. I'm sorry if I'm coming across as awfully bureaucratic and managerial; I'm really not trying to get in your way. If I'm being too conservative about this, it's because I don't want to be too liberal and confuse the hackers of the future as the hackers of the past have been... really the most important thing to avoid is the "how did this ever possibly work?" question, which is answered by "it didn't", but only after days of confusion. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Perry E. M. <pe...@pi...> - 2004-03-29 22:06:02
|
Christophe Rhodes <cs...@ca...> writes: > I don't suppose I can ask you to work on the branch, and then let me > deal with the integration issues? > > The reason it's likely to be easier is that once you're satisfied with > the NetBSD work, users of other platforms can test the accumulated > changes once, make sure everything still works, and then we can merge > the patch (obtainable by diffing the head of netbsd_branch with the > branch point) onto HEAD in one go. I'm trying not to touch anything that will be compiled on other platforms in doing the port -- if users of other platforms notice anything, I've done my job wrong. Just about everything I'm touching is only #ifdef or #!+ protected. (The warning removal stuff is a bit different but isn't critical to my work. Its mostly doing things like adding #include <string.h> and such in some of the files. I consider it a separate change set anyway.) > This means that firstly we only > have to deal with conflicts once, rather than every time someone else > touches any given bit of code; secondly, we don't have to test on our > rather large numbers of platforms each time you touch code that is > shared in a non-trivial way; thirdly, and probably most importantly, > until the NetBSD port works at least to the point of getting to the > first prompt Oh, it is well past that. Right now it partially works if I ktrace it and dies if I dont -- a probable kernel bug, actually. It is a bit beyond my understanding so I've called in heavy guns to help with it, and we should be committing the fixes to the NetBSD 2.0 branch before release. :) >>>> FYI, I have a lot more patches, some of them MI. I also have been >>>> working to reduce the number of warnings produced by the C compiler >>>> when building the run time... >>> >>> I don't know what "MI" means here, >> >> Machine independent, as opposed to "MD", machine dependent. I'm used >> to that jargon in other projects, though I suppose it isn't the lingo >> around here. > > Thanks. Machine-independent patches, similarly to > warnings-obliterating patches, will tend to be committed to HEAD > directly. Okay, should I be sending them to you then? A lot of them are literally just additions of things like #include <unistd.h> in reasonable places. (I've stuck as purely as possible to what POSIX says is correct in deciding on each change...) > If this is awful for you (because you only have one tree > where you have both sets of patches, say), No, that would be fine. When I CVS update they'll just get slurped in and I'll ignore the netbsd branch for now. I'm hoping to be done with the port within a few days in any case. > One way of making me feel happier about applying > effectively-untestable patches to CVS HEAD is to give some kind of an > indication of timeframe; if it's clear to you that all of the > integration issues and functionality will be ready in three weeks' > time or thereabouts, then some of my worries disappear, because the > changes will be effectively testable by the time our next release > period occurs. I'm almost certain we'll be done well before then. :) > I'm sorry if I'm coming across as awfully bureaucratic and managerial; > I'm really not trying to get in your way. No, don't worry. I'm the stranger -- this is your code base. I have to work with what makes you comfortable, not the other way around. Should I post my warning suppression patches to the mailing list for comment, or should I send them to someone directly? Perry |
From: Christophe R. <cs...@ca...> - 2004-03-29 22:30:04
|
"Perry E. Metzger" <pe...@pi...> writes: > Christophe Rhodes <cs...@ca...> writes: >> This means that firstly we only >> have to deal with conflicts once, rather than every time someone else >> touches any given bit of code; secondly, we don't have to test on our >> rather large numbers of platforms each time you touch code that is >> shared in a non-trivial way; thirdly, and probably most importantly, >> until the NetBSD port works at least to the point of getting to the >> first prompt > > Oh, it is well past that. Oh, good! :-) > Right now it partially works if I ktrace it > and dies if I dont -- a probable kernel bug, actually. It is a bit > beyond my understanding so I've called in heavy guns to help with it, > and we should be committing the fixes to the NetBSD 2.0 branch before > release. :) Right. This makes me feel a lot happier. >> I'm sorry if I'm coming across as awfully bureaucratic and managerial; >> I'm really not trying to get in your way. > > No, don't worry. I'm the stranger -- this is your code base. I have to > work with what makes you comfortable, not the other way around. > > Should I post my warning suppression patches to the mailing list for > comment, or should I send them to someone directly? Posting them here is great; it increases the chance that a maintainer with more POSIX-fu than me will look at them :-) Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |