From: Tom I. H. <ti...@ha...> - 2013-07-04 11:32:05
|
Just tried to build 1.1.9 on a couple of NetBSD hosts running NetBSD-current. It builds and runs fine on a NetBSD/amd64 system. On a NetBSD/i386 box, however, it crashes during the build process. The machine is already running sbcl 1.1.8, which happily recompiles itself from a "distclean" state. Here's how it looks: [...] obj/from-xc/src/code/late-cas.lisp-obj obj/from-xc/src/code/late-format.lisp-obj obj/from-xc/src/code/sxhash.lisp-obj obj/from-xc/src/code/signal.lisp-obj obj/from-xc/src/code/late-defbangmethod.lisp-obj obj/from-xc/src/pcl/walk.lisp-obj [building initial core file in "output/cold-sbcl.core": writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY> writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :STATIC> writing 28864512 bytes [7047 pages] from #<SB!FASL::GSPACE :DYNAMIC> /(DESCRIPTOR-BITS INITIAL-FUN)=#X61913DB5 done] * //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good 237.44 real 212.87 user 6.67 sys //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.1.9, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Argh! error in cold init, halting fatal error encountered in SBCL pid 9056: %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> backtrace Backtrace: 0: Foreign function ldb_monitor, fp = 0xbb4b9304, ra = 0x8056f4d 1: Foreign function lose, fp = 0xbb4b931c, ra = 0x805462f 2: Foreign function handle_trap, fp = 0xbb4b9338, ra = 0x80566aa 3: Foreign function sigabrt_handler, fp = 0xbb4b9364, ra = 0x8054b36 4: Foreign function __sigtramp_siginfo_2, fp = 0xbb4b9718, ra = 0xbbb18320 5: SB!KERNEL::INTERNAL-ERROR 6: Foreign function call_into_lisp, fp = 0xbb4b97dc, ra = 0x806127b 7: Foreign function funcall2, fp = 0xbb4b97f8, ra = 0x8051dab 8: Foreign function interrupt_internal_error, fp = 0xbb4b9818, ra = 0x80557dc 9: Foreign function sigabrt_handler, fp = 0xbb4b9844, ra = 0x8054b36 10: Foreign function __sigtramp_siginfo_2, fp = 0xbb4b9c18, ra = 0xbbb18320 11: SB!C::MAKE-SOURCE-INFO 12: (COMMON-LISP::LAMBDA () KEYWORD::IN SB!C::ACTUALLY-COMPILE) 13: (COMMON-LISP::FLET SB!C::WITH-IT KEYWORD::IN SB!C::%WITH-COMPILATION-UNIT) 14: SB!C::ACTUALLY-COMPILE 15: SB!C::COMPILE-IN-LEXENV 16: COMMON-LISP::COMPILE 17: COMMON-LISP::SET-PPRINT-DISPATCH 18: SB!PRETTY::!PPRINT-COLD-INIT 19: SB!KERNEL::!COLD-INIT ldb> -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Josh E. <jo...@el...> - 2013-07-04 11:45:25
|
On Thu, Jul 04, 2013 at 01:14:39PM +0200, Tom Ivar Helbekkmo wrote: > Just tried to build 1.1.9 on a couple of NetBSD hosts running > NetBSD-current. It builds and runs fine on a NetBSD/amd64 system. On a > NetBSD/i386 box, however, it crashes during the build process. The > machine is already running sbcl 1.1.8, which happily recompiles itself > from a "distclean" state. Here's how it looks: Could I get a look at the output/stuff-groveled-from-headers.lisp file from both hosts with 1.1.9? > [...] > obj/from-xc/src/code/late-cas.lisp-obj > obj/from-xc/src/code/late-format.lisp-obj > obj/from-xc/src/code/sxhash.lisp-obj > obj/from-xc/src/code/signal.lisp-obj > obj/from-xc/src/code/late-defbangmethod.lisp-obj > obj/from-xc/src/pcl/walk.lisp-obj > [building initial core file in "output/cold-sbcl.core": > writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY> > writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :STATIC> > writing 28864512 bytes [7047 pages] from #<SB!FASL::GSPACE :DYNAMIC> > /(DESCRIPTOR-BITS INITIAL-FUN)=#X61913DB5 > done] > * //testing for consistency of first and second GENESIS passes > //header files match between first and second GENESIS -- good > 237.44 real 212.87 user 6.67 sys > //entering make-target-2.sh > //doing warm init - compilation phase > This is SBCL 1.1.9, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > Argh! error in cold init, halting > fatal error encountered in SBCL pid 9056: > %PRIMITIVE HALT called; the party is over. > > > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> backtrace > Backtrace: > 0: Foreign function ldb_monitor, fp = 0xbb4b9304, ra = 0x8056f4d > 1: Foreign function lose, fp = 0xbb4b931c, ra = 0x805462f > 2: Foreign function handle_trap, fp = 0xbb4b9338, ra = 0x80566aa > 3: Foreign function sigabrt_handler, fp = 0xbb4b9364, ra = 0x8054b36 > 4: Foreign function __sigtramp_siginfo_2, fp = 0xbb4b9718, ra = 0xbbb18320 > 5: SB!KERNEL::INTERNAL-ERROR > 6: Foreign function call_into_lisp, fp = 0xbb4b97dc, ra = 0x806127b > 7: Foreign function funcall2, fp = 0xbb4b97f8, ra = 0x8051dab > 8: Foreign function interrupt_internal_error, fp = 0xbb4b9818, ra = 0x80557dc > 9: Foreign function sigabrt_handler, fp = 0xbb4b9844, ra = 0x8054b36 > 10: Foreign function __sigtramp_siginfo_2, fp = 0xbb4b9c18, ra = 0xbbb18320 > 11: SB!C::MAKE-SOURCE-INFO > 12: (COMMON-LISP::LAMBDA () KEYWORD::IN SB!C::ACTUALLY-COMPILE) > 13: (COMMON-LISP::FLET SB!C::WITH-IT KEYWORD::IN SB!C::%WITH-COMPILATION-UNIT) > 14: SB!C::ACTUALLY-COMPILE > 15: SB!C::COMPILE-IN-LEXENV > 16: COMMON-LISP::COMPILE > 17: COMMON-LISP::SET-PPRINT-DISPATCH > 18: SB!PRETTY::!PPRINT-COLD-INIT > 19: SB!KERNEL::!COLD-INIT > ldb> > > -tih > -- > It doesn't matter how beautiful your theory is, it doesn't matter how smart > you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Tom I. H. <ti...@ha...> - 2013-07-04 11:58:16
|
Josh Elsasser <jo...@el...> writes: > Could I get a look at the output/stuff-groveled-from-headers.lisp file > from both hosts with 1.1.9? Sure. Inlining them, one after the other, as I assume the mailing list system won't like attachments. Here's the one from NetBSD/amd64-current: ;;;; This is an automatically generated file, please do not hand-edit it. ;;;; See the program "grovel-headers.c". (in-package "SB!ALIEN") ;;;flags for dlopen() (defconstant rtld-lazy 1) ; #x1 (defconstant rtld-now 2) ; #x2 (defconstant rtld-global 256) ; #x100 (in-package "SB!UNIX") ;;; select() (defconstant fd-setsize 256) ; #x100 ;;; poll() (defconstant pollin 1) ; #x1 (defconstant pollout 4) ; #x4 (defconstant pollpri 2) ; #x2 (defconstant pollhup 16) ; #x10 (define-alien-type nfds-t (unsigned 32)) ;;; langinfo (defconstant codeset 51) ; #x33 ;;; types, types, types (define-alien-type clock-t (unsigned 32)) (define-alien-type dev-t (unsigned 64)) (define-alien-type gid-t (unsigned 32)) (define-alien-type ino-t (unsigned 64)) (define-alien-type mode-t (unsigned 32)) (define-alien-type nlink-t (unsigned 32)) (define-alien-type off-t (sb!alien:signed 64)) (define-alien-type size-t (unsigned 64)) (define-alien-type time-t (sb!alien:signed 64)) (define-alien-type suseconds-t (sb!alien:signed 32)) (define-alien-type uid-t (unsigned 32)) ;; Types in src/runtime/wrap.h. See that file for explantion. ;; Don't use these types for anything other than the stat wrapper. (define-alien-type wst-dev-t (unsigned 32)) (define-alien-type wst-off-t (unsigned 32)) (define-alien-type wst-blksize-t (sb!alien:signed 32)) (define-alien-type wst-blkcnt-t (sb!alien:signed 64)) (define-alien-type wst-nlink-t (unsigned 32)) (define-alien-type wst-uid-t (unsigned 32)) (define-alien-type wst-gid-t (unsigned 32)) ;;; fcntl.h (or unistd.h on OpenBSD and NetBSD) (defconstant r_ok 4) ; #x4 (defconstant w_ok 2) ; #x2 (defconstant x_ok 1) ; #x1 (defconstant f_ok 0) ; #x0 ;;; fcntlbits.h (defconstant o_rdonly 0) ; #x0 (defconstant o_wronly 1) ; #x1 (defconstant o_rdwr 2) ; #x2 (defconstant o_accmode 3) ; #x3 (defconstant o_creat 512) ; #x200 (defconstant o_excl 2048) ; #x800 (defconstant o_noctty 32768) ; #x8000 (defconstant o_trunc 1024) ; #x400 (defconstant o_append 8) ; #x8 ;;; (defconstant s-ifmt 61440) ; #xf000 (defconstant s-ififo 4096) ; #x1000 (defconstant s-ifchr 8192) ; #x2000 (defconstant s-ifdir 16384) ; #x4000 (defconstant s-ifblk 24576) ; #x6000 (defconstant s-ifreg 32768) ; #x8000 (defconstant s-iflnk 40960) ; #xa000 (defconstant s-ifsock 49152) ; #xc000 ;;; error numbers (defconstant ebadf 9) ; #x9 (defconstant enoent 2) ; #x2 (defconstant eintr 4) ; #x4 (defconstant eagain 35) ; #x23 (defconstant eio 5) ; #x5 (defconstant eexist 17) ; #x11 (defconstant eloop 62) ; #x3e (defconstant espipe 29) ; #x1d (defconstant ewouldblock 35) ; #x23 ;;; for wait3(2) in run-program.lisp (defconstant wnohang 1) ; #x1 (defconstant wuntraced 2) ; #x2 ;;; various ioctl(2) flags (defconstant tiocgpgrp 1074033783) ; #x40047477 (defconstant tiocspgrp 2147775606) ; #x80047476 (defconstant tiocgwinsz 1074295912) ; #x40087468 (defconstant tiocswinsz 2148037735) ; #x80087467 ;;; signals (defconstant sig-dfl 0) ; #x0 (defconstant sig-ign 1) ; #x1 (defconstant sigalrm 14) ; #xe (defconstant sigbus 10) ; #xa (defconstant sigchld 20) ; #x14 (defconstant sigcont 19) ; #x13 (defconstant sigemt 7) ; #x7 (defconstant sigfpe 8) ; #x8 (defconstant sighup 1) ; #x1 (defconstant sigill 4) ; #x4 (defconstant sigint 2) ; #x2 (defconstant sigio 23) ; #x17 (defconstant sigiot 6) ; #x6 (defconstant sigkill 9) ; #x9 (defconstant sigpipe 13) ; #xd (defconstant sigprof 27) ; #x1b (defconstant sigquit 3) ; #x3 (defconstant sigsegv 11) ; #xb (defconstant sigstop 17) ; #x11 (defconstant sigsys 12) ; #xc (defconstant sigterm 15) ; #xf (defconstant sigtrap 5) ; #x5 (defconstant sigtstp 18) ; #x12 (defconstant sigttin 21) ; #x15 (defconstant sigttou 22) ; #x16 (defconstant sigurg 16) ; #x10 (defconstant sigusr1 30) ; #x1e (defconstant sigusr2 31) ; #x1f (defconstant sigvtalrm 26) ; #x1a (defconstant sigwinch 28) ; #x1c (defconstant sigxcpu 24) ; #x18 (defconstant sigxfsz 25) ; #x19 (defconstant fpe-intovf 2) ; #x2 (defconstant fpe-intdiv 1) ; #x1 (defconstant fpe-fltdiv 3) ; #x3 (defconstant fpe-fltovf 4) ; #x4 (defconstant fpe-fltund 5) ; #x5 (defconstant fpe-fltres 6) ; #x6 (defconstant fpe-fltinv 7) ; #x7 (defconstant fpe-fltsub 8) ; #x8 ;;; structures (define-alien-type nil (struct timeval (tv-sec (sb!alien:signed 64)) (tv-usec (sb!alien:signed 32)))) (define-alien-type nil (struct timespec (tv-sec (sb!alien:signed 64)) (tv-nsec (sb!alien:signed 64)))) ;;; sysctl(3) names (in-package "SB!IMPL") (defconstant ctl-kern 1) ; #x1 (defconstant ctl-hw 6) ; #x6 (defconstant ctl-maxname 12) ; #xc (defconstant kern-ostype 1) ; #x1 (defconstant kern-osrelease 2) ; #x2 (defconstant hw-model 2) ; #x2 (defconstant hw-pagesize 7) ; #x7 (in-package "SB!KERNEL") ;;; GENCGC related (define-alien-type page-index-t (sb!alien:signed 64)) (define-alien-type generation-index-t (sb!alien:signed 8)) ;;; Our runtime types (define-alien-type os-vm-size-t (unsigned 64)) ...and here's the one from NetBSD/i386-current: ;;;; This is an automatically generated file, please do not hand-edit it. ;;;; See the program "grovel-headers.c". (in-package "SB!ALIEN") ;;;flags for dlopen() (defconstant rtld-lazy 1) ; #x1 (defconstant rtld-now 2) ; #x2 (defconstant rtld-global 256) ; #x100 (in-package "SB!UNIX") ;;; select() (defconstant fd-setsize 256) ; #x100 ;;; poll() (defconstant pollin 1) ; #x1 (defconstant pollout 4) ; #x4 (defconstant pollpri 2) ; #x2 (defconstant pollhup 16) ; #x10 (define-alien-type nfds-t (unsigned 32)) ;;; langinfo (defconstant codeset 51) ; #x33 ;;; types, types, types (define-alien-type clock-t (unsigned 32)) (define-alien-type dev-t (unsigned 64)) (define-alien-type gid-t (unsigned 32)) (define-alien-type ino-t (unsigned 64)) (define-alien-type mode-t (unsigned 32)) (define-alien-type nlink-t (unsigned 32)) (define-alien-type off-t (sb!alien:signed 64)) (define-alien-type size-t (unsigned 32)) (define-alien-type time-t (sb!alien:signed 64)) (define-alien-type suseconds-t (sb!alien:signed 32)) (define-alien-type uid-t (unsigned 32)) ;; Types in src/runtime/wrap.h. See that file for explantion. ;; Don't use these types for anything other than the stat wrapper. (define-alien-type wst-dev-t (unsigned 32)) (define-alien-type wst-off-t (unsigned 32)) (define-alien-type wst-blksize-t (sb!alien:signed 32)) (define-alien-type wst-blkcnt-t (sb!alien:signed 64)) (define-alien-type wst-nlink-t (unsigned 32)) (define-alien-type wst-uid-t (unsigned 32)) (define-alien-type wst-gid-t (unsigned 32)) ;;; fcntl.h (or unistd.h on OpenBSD and NetBSD) (defconstant r_ok 4) ; #x4 (defconstant w_ok 2) ; #x2 (defconstant x_ok 1) ; #x1 (defconstant f_ok 0) ; #x0 ;;; fcntlbits.h (defconstant o_rdonly 0) ; #x0 (defconstant o_wronly 1) ; #x1 (defconstant o_rdwr 2) ; #x2 (defconstant o_accmode 3) ; #x3 (defconstant o_creat 512) ; #x200 (defconstant o_excl 2048) ; #x800 (defconstant o_noctty 32768) ; #x8000 (defconstant o_trunc 1024) ; #x400 (defconstant o_append 8) ; #x8 ;;; (defconstant s-ifmt 61440) ; #xf000 (defconstant s-ififo 4096) ; #x1000 (defconstant s-ifchr 8192) ; #x2000 (defconstant s-ifdir 16384) ; #x4000 (defconstant s-ifblk 24576) ; #x6000 (defconstant s-ifreg 32768) ; #x8000 (defconstant s-iflnk 40960) ; #xa000 (defconstant s-ifsock 49152) ; #xc000 ;;; error numbers (defconstant ebadf 9) ; #x9 (defconstant enoent 2) ; #x2 (defconstant eintr 4) ; #x4 (defconstant eagain 35) ; #x23 (defconstant eio 5) ; #x5 (defconstant eexist 17) ; #x11 (defconstant eloop 62) ; #x3e (defconstant espipe 29) ; #x1d (defconstant ewouldblock 35) ; #x23 ;;; for wait3(2) in run-program.lisp (defconstant wnohang 1) ; #x1 (defconstant wuntraced 2) ; #x2 ;;; various ioctl(2) flags (defconstant tiocgpgrp 1074033783) ; #x40047477 (defconstant tiocspgrp 2147775606) ; #x80047476 (defconstant tiocgwinsz 1074295912) ; #x40087468 (defconstant tiocswinsz 2148037735) ; #x80087467 ;;; signals (defconstant sig-dfl 0) ; #x0 (defconstant sig-ign 1) ; #x1 (defconstant sigalrm 14) ; #xe (defconstant sigbus 10) ; #xa (defconstant sigchld 20) ; #x14 (defconstant sigcont 19) ; #x13 (defconstant sigemt 7) ; #x7 (defconstant sigfpe 8) ; #x8 (defconstant sighup 1) ; #x1 (defconstant sigill 4) ; #x4 (defconstant sigint 2) ; #x2 (defconstant sigio 23) ; #x17 (defconstant sigiot 6) ; #x6 (defconstant sigkill 9) ; #x9 (defconstant sigpipe 13) ; #xd (defconstant sigprof 27) ; #x1b (defconstant sigquit 3) ; #x3 (defconstant sigsegv 11) ; #xb (defconstant sigstop 17) ; #x11 (defconstant sigsys 12) ; #xc (defconstant sigterm 15) ; #xf (defconstant sigtrap 5) ; #x5 (defconstant sigtstp 18) ; #x12 (defconstant sigttin 21) ; #x15 (defconstant sigttou 22) ; #x16 (defconstant sigurg 16) ; #x10 (defconstant sigusr1 30) ; #x1e (defconstant sigusr2 31) ; #x1f (defconstant sigvtalrm 26) ; #x1a (defconstant sigwinch 28) ; #x1c (defconstant sigxcpu 24) ; #x18 (defconstant sigxfsz 25) ; #x19 (defconstant fpe-intovf 2) ; #x2 (defconstant fpe-intdiv 1) ; #x1 (defconstant fpe-fltdiv 3) ; #x3 (defconstant fpe-fltovf 4) ; #x4 (defconstant fpe-fltund 5) ; #x5 (defconstant fpe-fltres 6) ; #x6 (defconstant fpe-fltinv 7) ; #x7 (defconstant fpe-fltsub 8) ; #x8 ;;; structures (define-alien-type nil (struct timeval (tv-sec (sb!alien:signed 64)) (tv-usec (sb!alien:signed 32)))) (define-alien-type nil (struct timespec (tv-sec (sb!alien:signed 64)) (tv-nsec (sb!alien:signed 32)))) ;;; sysctl(3) names (in-package "SB!IMPL") (defconstant ctl-kern 1) ; #x1 (defconstant ctl-hw 6) ; #x6 (defconstant ctl-maxname 12) ; #xc (defconstant kern-ostype 1) ; #x1 (defconstant kern-osrelease 2) ; #x2 (defconstant hw-model 2) ; #x2 (defconstant hw-pagesize 7) ; #x7 (in-package "SB!KERNEL") ;;; GENCGC related (define-alien-type page-index-t (sb!alien:signed 32)) (define-alien-type generation-index-t (sb!alien:signed 8)) ;;; Our runtime types (define-alien-type os-vm-size-t (unsigned 32)) -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Josh E. <jo...@el...> - 2013-07-04 13:27:25
|
On Thu, Jul 04, 2013 at 01:58:07PM +0200, Tom Ivar Helbekkmo wrote: > Josh Elsasser <jo...@el...> writes: > > > Could I get a look at the output/stuff-groveled-from-headers.lisp file > > from both hosts with 1.1.9? > > Sure. Inlining them, one after the other, as I assume the mailing list > system won't like attachments. I had thought that this was a result of the struct timeval/timespec change I made, but based on my reading of the netbsd headers and your grovel output, the alien struct definitions should be correct now. In fact, it's surprising that it worked at all on i386 before. However if you'd like to try bisecting between 1.1.8 and 1.1.9, the commit where I changed the struct groveling is 7230b50bc438a7fbebd93866a96f9291e630419f |
From: Tom I. H. <ti...@ha...> - 2013-07-05 09:27:53
|
Josh Elsasser <jo...@el...> writes: > I had thought that this was a result of the struct timeval/timespec > change I made, but based on my reading of the netbsd headers and your > grovel output, the alien struct definitions should be correct now. In > fact, it's surprising that it worked at all on i386 before. It didn't -- I've been running with a local modification to omit testing of those particular bits for quite some time: --- contrib/sb-posix/posix-tests.lisp 30 Mar 2011 16:48:49 -0000 1.52 +++ contrib/sb-posix/posix-tests.lisp 15 Feb 2013 21:50:48 -0000 @@ -657,7 +657,7 @@ (plusp (sb-posix:time)) t) -#-win32 +#-(or win32 netbsd) ; netbsd fails because of 64 bit time_t (deftest utimes.1 (let ((file (merge-pathnames #p"utimes.1" *test-directory*)) (atime (random (1- (expt 2 31)))) > However if you'd like to try bisecting between 1.1.8 and 1.1.9, the > commit where I changed the struct groveling is > 7230b50bc438a7fbebd93866a96f9291e630419f Well, that didn't take long to verify. That's exactly where it breaks. Checking out to the previous commit (that is, the next one down in the output of 'git log') results in a good build; checking out to that one, the build crashes as previously shown. -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Josh E. <jo...@el...> - 2013-07-05 15:31:44
|
On Fri, Jul 05, 2013 at 11:27:44AM +0200, Tom Ivar Helbekkmo wrote: > Josh Elsasser <jo...@el...> writes: > > > I had thought that this was a result of the struct timeval/timespec > > change I made, but based on my reading of the netbsd headers and your > > grovel output, the alien struct definitions should be correct now. In > > fact, it's surprising that it worked at all on i386 before. > > It didn't -- I've been running with a local modification to omit testing > of those particular bits for quite some time: > > --- contrib/sb-posix/posix-tests.lisp 30 Mar 2011 16:48:49 -0000 1.52 > +++ contrib/sb-posix/posix-tests.lisp 15 Feb 2013 21:50:48 -0000 > @@ -657,7 +657,7 @@ > (plusp (sb-posix:time)) > t) > > -#-win32 > +#-(or win32 netbsd) ; netbsd fails because of 64 bit time_t > (deftest utimes.1 > (let ((file (merge-pathnames #p"utimes.1" *test-directory*)) > (atime (random (1- (expt 2 31)))) > > > > However if you'd like to try bisecting between 1.1.8 and 1.1.9, the > > commit where I changed the struct groveling is > > 7230b50bc438a7fbebd93866a96f9291e630419f > > Well, that didn't take long to verify. That's exactly where it breaks. > Checking out to the previous commit (that is, the next one down in the > output of 'git log') results in a good build; checking out to that one, > the build crashes as previously shown. It is mystifying to me that changing struct timeval and timespec to the correct 64-bit time_t type would break the build on a 64-bit time_t system. I'll have to set up a netbsd box and take a look at what's going on. |
From: Tom I. H. <ti...@ha...> - 2013-07-10 19:59:01
|
Josh Elsasser <jo...@el...> writes: > It is mystifying to me that changing struct timeval and timespec to > the correct 64-bit time_t type would break the build on a 64-bit > time_t system. I'll have to set up a netbsd box and take a look at > what's going on. Mystifying, indeed. I've been playing with lots of changes to different versions of sbcl, and am starting to get a rudimentary feel for the code. However, I cannot understand why some instances of time values are of type "(unsigned-byte 32)", some "(unsigned-byte 31)", and some "(unsigned-byte 29)". I've gotten sbcl to build with these values changed based on the actual time being a 64 bit value, but I tend to end up with running systems where (get-time-of-day) shows obvious byte order problems, and crashes randomly. Some guidance would be appreciated. :) -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Robert S. <rj...@fd...> - 2013-07-05 23:39:51
|
Josh Elsasser wrote: >It is mystifying to me that changing struct timeval and timespec to >the correct 64-bit time_t type would break the build on a 64-bit >time_t system. I'll have to set up a netbsd box and take a look at >what's going on. I think your change to grovel the values just poked something that worked by chance before. I believe the problem is with get-internal-real-time, it is called by make-source-info but is declared as inline so doesn't show up in the backtrace. The declarations of time values as (unsigned-byte 32) look wrong to me. I also think that NetBSD should use the same logic as darwin in get-time-of-day. Robert Swindells |
From: Tom I. H. <ti...@ha...> - 2013-07-06 07:40:33
|
Robert Swindells <rj...@fd...> writes: > I believe the problem is with get-internal-real-time, it is called by > make-source-info but is declared as inline so doesn't show up in the > backtrace. The declarations of time values as (unsigned-byte 32) look > wrong to me. Looks like you're on to something. The actual crash is in gettimeofday(2): 28231 1 sbcl CALL __sigaction_sigtramp(SIGCHLD,0xbb4b9de4,0,0xbbb14bf0,2) 28231 1 sbcl RET __sigaction_sigtramp 0 28231 1 sbcl CALL __sigprocmask14(3,0xbb4b9dfc,0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(2,0x806cd64,0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(1,0,0xbb4b9e48) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(2,0x806cd40,0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __gettimeofday50(0xbb4b9bcc,0xbb6b9fe8) 28231 1 sbcl RET __gettimeofday50 0 28231 1 sbcl CALL __gettimeofday50(0xbb4b9bac,0xbb6b9fe8) 28231 1 sbcl RET __gettimeofday50 0 28231 1 sbcl PSIG SIGTRAP caught handler=0x8054aba mask=(1,2,3,5,13,14,15,16,18,20,23,24,25,26,27,28): code=TRAP_BRKPT, addr=0x60255774, trap=1) 28231 1 sbcl CALL __sigprocmask14(2,0xbb4b982c,0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(1,0,0xbb4b97a0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(2,0x806cd64,0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(1,0,0xbb4b978c) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(3,0xbb4b98e0,0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(1,0,0xbb4b97a0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL write(2,0xbb4b8f54,0x22) 28231 1 sbcl GIO fd 2 wrote 34 bytes "Argh! error in cold init, halting\n" 28231 1 sbcl RET write 34/0x22 28231 1 sbcl PSIG SIGTRAP caught handler=0x8054aba mask=(1,2,3,5,13,14,15,16,18,20,23,24,25,26,27,28): code=TRAP_BRKPT, addr=0x600f31c9, trap=1) 28231 1 sbcl CALL __sigprocmask14(2,0xbb4b934c,0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(1,0,0xbb4b92c4) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL __sigprocmask14(1,0x806cd50,0) 28231 1 sbcl RET __sigprocmask14 0 28231 1 sbcl CALL write(2,0x8062c74,0x17) 28231 1 sbcl GIO fd 2 wrote 23 bytes "fatal error encountered" 28231 1 sbcl RET write 23/0x17 -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Tom I. H. <ti...@ha...> - 2013-07-06 08:53:50
|
I wrote: > Looks like you're on to something. The actual crash is in gettimeofday(2): Sorry -- I somehow missed the RET. That should be: the last system call before the crash is to gettimeofday(2), indicating that the problem may be with the processing of the data returned by it. -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Robert S. <rj...@fd...> - 2013-07-06 19:22:29
|
Tom Ivar Helbekkmo <ti...@ha...> wrote: >> Looks like you're on to something. The actual crash is in gettimeofday(2): > >Sorry -- I somehow missed the RET. That should be: the last system call >before the crash is to gettimeofday(2), indicating that the problem may >be with the processing of the data returned by it. There are two call and returns of gettimeofday(2) in your ktrace listing, they match the first two fields of the SOURCE-INFO structure, the second one is within a call to I have given up on this, I can't see any combination of declarations that will build. I can build you a SBCL binary on NetBSD/i386 5.2 if it helps, that is how I build CMUCL. Robert Swindells |
From: Tom I. H. <ti...@ha...> - 2013-07-11 18:46:52
|
Josh Elsasser <jo...@el...> writes: > It is mystifying to me that changing struct timeval and timespec to > the correct 64-bit time_t type would break the build on a 64-bit > time_t system. I'll have to set up a netbsd box and take a look at > what's going on. I've got a bit more of a handle on it, now. As it turns out, the crashes are because data returned by get-time-of-day (and unix-fast-getrusage, as well) are wrong, and break assertions. After much experimentation down the wrong paths, I changed both of them to return fake, but good, data, in addition to the bad bits. Here's the relevant part of get-time-of-day: (defvar *fake-tod-value* 1373538840) [...] (defun get-time-of-day () [...] (with-alien ((tv (struct timeval))) (syscall* ("gettimeofday" (* (struct timeval)) (* (struct timezone))) (values (incf *fake-tod-value*) 0 (slot tv 'tv-sec) (slot tv 'tv-usec)) (addr tv) nil)) Note that I've extended it from returning two values to returning four, where the first two are fake, and the last two are the original ones that don't work. With this modification, I got sbcl, checked out at the exact commit where the groveling for the timeval structure and time_t were introduced, to actually build and run. Look at this: * (get-time-of-day) 1373539778 0 365185262860240 65539 * (get-time-of-day) 1373539780 0 1029543689107410 65539 * (get-time-of-day) 1373539782 0 1783984759420882 65539 * (get-time-of-day) 1373539784 0 1134315121326035 65539 * (get-time-of-day) 1373539786 0 1650935262525396 65539 * (get-time-of-day) 1373539788 0 2416191060490197 65539 Note that tv-sec is much too large, and keeps varying immensely, while tv-usec is stuck at the same value all the time. We see why here: * (format t "~X" 365185262860240) 14C2251DEB7D0 NIL * (format t "~X" 1029543689107410) 3A85D51DEB7D2 NIL * (format t "~X" 1783984759420882) 6568651DEB7D2 NIL * (format t "~X" 1134315121326035) 407A751DEB7D3 NIL * (format t "~X" 1650935262525396) 5DD8451DEB7D4 NIL * (format t "~X" 2416191060490197) 8958351DEB7D5 NIL It's rather obvious that the lower 32 bits of the tv-sec value is the proper value (the 51DE.... subsequence is the correct number of seconds since the epoch), while the upper 32 bits vary wildly. I would hazard a guess that the upper 32 bits are actually the tv-usec value: note that they always present a legal value for it. The proper tv-usec slot doesn't get updated, and probably just contains random garbage. Since this works on NetBSD/amd64, I would (really intuitively, with no actual basis) guess that it comes down to the use of "long" somewhere in the C code, which is 32 bits on NetBSD/i386, 64 bits on NetBSD/amd64. Any ideas, before I start trying to understand the underlying C code? -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Paul K. <pv...@pv...> - 2013-07-11 18:55:14
|
Tom Ivar Helbekkmo wrote: [...] > It's rather obvious that the lower 32 bits of the tv-sec value is the > proper value (the 51DE.... subsequence is the correct number of seconds > since the epoch), while the upper 32 bits vary wildly. I would hazard a > guess that the upper 32 bits are actually the tv-usec value: note that > they always present a legal value for it. The proper tv-usec slot > doesn't get updated, and probably just contains random garbage. > > Since this works on NetBSD/amd64, I would (really intuitively, with no > actual basis) guess that it comes down to the use of "long" somewhere in > the C code, which is 32 bits on NetBSD/i386, 64 bits on NetBSD/amd64. Is it possible that, while your machine's headers are >= 6.0, its libc is somehow < 6.0 (i.e. pre 64-bit time_t everywhere)? That would fit perfectly with the corruption you describe. A tiny C program would easily test that hypothesis. Make a timeval, memset it with noise, and see if it's over-written by gettimeofday as expected with a __int64_t time_t, or if it instead looks like a long time_t. Paul Khuong |
From: Josh E. <jo...@el...> - 2013-07-11 19:19:21
|
On Thu, Jul 11, 2013 at 02:55:01PM -0400, Paul Khuong wrote: > Tom Ivar Helbekkmo wrote: > [...] > >It's rather obvious that the lower 32 bits of the tv-sec value is the > >proper value (the 51DE.... subsequence is the correct number of seconds > >since the epoch), while the upper 32 bits vary wildly. I would hazard a > >guess that the upper 32 bits are actually the tv-usec value: note that > >they always present a legal value for it. The proper tv-usec slot > >doesn't get updated, and probably just contains random garbage. > > > >Since this works on NetBSD/amd64, I would (really intuitively, with no > >actual basis) guess that it comes down to the use of "long" somewhere in > >the C code, which is 32 bits on NetBSD/i386, 64 bits on NetBSD/amd64. > > Is it possible that, while your machine's headers are >= 6.0, its libc is somehow < 6.0 (i.e. pre 64-bit time_t everywhere)? That would fit perfectly with the corruption you describe. > > A tiny C program would easily test that hypothesis. Make a timeval, memset it with noise, and see if it's over-written by gettimeofday as expected with a __int64_t time_t, or if it instead looks like a long time_t. > > Paul Khuong Something like this is the only thing that makes sense based on what I've seen. I've also heard that NetBSD has some complex ABI backwards-compatibility mechanisms, perhaps that is going wrong somehow. |
From: Tom I. H. <ti...@ha...> - 2013-07-11 19:49:28
|
Paul Khuong <pv...@pv...> writes: > Is it possible that, while your machine's headers are >= 6.0, its libc > is somehow < 6.0 (i.e. pre 64-bit time_t everywhere)? That would fit > perfectly with the corruption you describe. Yeah, but I'm running NetBSD-current, and have everything up to date. Both i386 and amd64 systems are built from sources dated June 26th. > A tiny C program would easily test that hypothesis. Make a timeval, > memset it with noise, and see if it's over-written by gettimeofday as > expected with a __int64_t time_t, or if it instead looks like a long > time_t. This actually does uncover a slight difference between NetBSD-current on amd64 and i386. Here's the test program: #include <stdio.h> #include <sys/time.h> int main (int argc, char **argv) { struct timeval tv; tv.tv_sec = 0xDEADBEEFDEADBEEF; tv.tv_usec = 0xDEADBEEF; gettimeofday(&tv, NULL); printf("%016X.%06d\n", tv.tv_sec, tv.tv_usec); return 0; } Now, on NetBSD/amd64-current, this looks like so: barsoom# ./gettimeofday 0000000051DF07EE.714298 barsoom# ./gettimeofday 0000000051DF07EF.678779 barsoom# ./gettimeofday 0000000051DF07F0.345564 barsoom# ./gettimeofday 0000000051DF07F1.214369 NetBSD/i386-current, however, simply zeroes the tv_usec field (the resolution of the time supplied by this system call is documented to be hardware dependent): athene$ ./gettimeofday 0000000051DF081E.000000 athene$ ./gettimeofday 0000000051DF0820.000000 athene$ ./gettimeofday 0000000051DF0820.000000 athene$ ./gettimeofday 0000000051DF0821.000000 -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Robert S. <rj...@fd...> - 2013-07-11 19:38:24
|
Paul Khuong wrote: >Tom Ivar Helbekkmo wrote: >[...] >> It's rather obvious that the lower 32 bits of the tv-sec value is the >> proper value (the 51DE.... subsequence is the correct number of seconds >> since the epoch), while the upper 32 bits vary wildly. I would hazard a >> guess that the upper 32 bits are actually the tv-usec value: note that >> they always present a legal value for it. The proper tv-usec slot >> doesn't get updated, and probably just contains random garbage. >> >> Since this works on NetBSD/amd64, I would (really intuitively, with no >> actual basis) guess that it comes down to the use of "long" somewhere in >> the C code, which is 32 bits on NetBSD/i386, 64 bits on NetBSD/amd64. >Is it possible that, while your machine's headers are >= 6.0, its libc >is somehow < 6.0 (i.e. pre 64-bit time_t everywhere)? That would fit >perfectly with the corruption you describe. I see the same problem and all the components of my system match as they were all built together. You may have prompted the answer though, some of the symbols for syscalls on NetBSD are renamed by the preprocessor in order to allow them to coexist with older versions, I'm not sure that the declarations in undefineds.[ch] and ldso_stubs.S will pick this up. >A tiny C program would easily test that hypothesis. Make a timeval, >memset it with noise, and see if it's over-written by gettimeofday as >expected with a __int64_t time_t, or if it instead looks like a long >time_t. It will work fine, the headers will fix up the syscall names so that you call the 64 bit version. Robert Swindells |
From: Tom I. H. <ti...@ha...> - 2013-07-11 20:07:03
|
Robert Swindells <rj...@fd...> writes: > You may have prompted the answer though, some of the symbols for > syscalls on NetBSD are renamed by the preprocessor in order to allow > them to coexist with older versions, I'm not sure that the declarations > in undefineds.[ch] and ldso_stubs.S will pick this up. Ah! The ktrace output I posted earlier shows that the actual system call is to "gettimeofday50", which looks like it may be a compatibility version for older code. So it's going to put tv_sec in the first 32 bits of the structure, and tv_usec in the next 32, and then sbcl is going to interpret all of that as tv_sec, and get 0 for tv_usec, sitting untouched behind it. Since the box is little-endian, tv_usec ends up where my tests showed it. This makes a lot of sense. However, running nm on my little test program shows that it wants the external name "gettimeofday50" resolved at run time, on both platforms. Since it obviously works, it may well be wrapped in some magic that happens at compile time, of course, and that the mechanisms used in sbcl somehow stumble over. -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Robert S. <rj...@fd...> - 2013-07-11 20:32:31
|
Tom Ivar Helbekkmo <ti...@ha...> wrote: >Robert Swindells <rj...@fd...> writes: > >> You may have prompted the answer though, some of the symbols for >> syscalls on NetBSD are renamed by the preprocessor in order to allow >> them to coexist with older versions, I'm not sure that the declarations >> in undefineds.[ch] and ldso_stubs.S will pick this up. >Ah! The ktrace output I posted earlier shows that the actual system >call is to "gettimeofday50", which looks like it may be a compatibility >version for older code. So it's going to put tv_sec in the first 32 >bits of the structure, and tv_usec in the next 32, and then sbcl is >going to interpret all of that as tv_sec, and get 0 for tv_usec, sitting >untouched behind it. Since the box is little-endian, tv_usec ends up >where my tests showed it. It is the other way around, __gettimeofday50() is the new syscall, there is also a function gettimeofday() in libc that will accept the old arguments and do any conversion to what is needed and returned by the new syscall. This way, old dynamically linked applications will still work even though they are loading a new libc. If you look at a log of the build of sbcl you will see several lines of the form: undefineds.o:(.data+0xb8): warning: warning: reference to compatibility gettimeofday(); include <sys/time.h> to generate correct reference These are generated if the linker if it tries to link to an old version of a syscall. >This makes a lot of sense. >However, running nm on my little test program shows that it wants the >external name "gettimeofday50" resolved at run time, on both platforms. >Since it obviously works, it may well be wrapped in some magic that >happens at compile time, of course, and that the mechanisms used in sbcl >somehow stumble over. The compile time magic is just to replace calls to gettimeofday() with ones to __gettimeofday50(). Doing a similar substitution in lisp source may be hard. Robert Swindells |
From: Nikodemus S. <nik...@ra...> - 2013-07-11 22:08:10
|
On 11 July 2013 23:28, Robert Swindells <rj...@fd...> wrote: > The compile time magic is just to replace calls to gettimeofday() with > ones to __gettimeofday50(). > > Doing a similar substitution in lisp source may be hard. We already have some os_foo() wrappers in the runtime for other things. Maybe the simplest thing would be to just add one for gettimeofday() as well. Cheers, -- nikodemus |
From: Robert S. <rj...@fd...> - 2013-07-11 22:39:11
|
Nikodemus Siivola <nik...@ra...> wrote: >On 11 July 2013 23:28, Robert Swindells <rj...@fd...> wrote: > >> The compile time magic is just to replace calls to gettimeofday() with >> ones to __gettimeofday50(). >> >> Doing a similar substitution in lisp source may be hard. > >We already have some os_foo() wrappers in the runtime for other >things. Maybe the simplest thing would be to just add one for >gettimeofday() as well. You would need wrappers for quite a few syscalls, I will collect a list. |
From: Robert S. <rj...@fd...> - 2013-07-12 11:17:05
|
I wrote: >>Nikodemus Siivola <nik...@ra...> wrote: >>On 11 July 2013 23:28, Robert Swindells <rj...@fd...> wrote: >> >>> The compile time magic is just to replace calls to gettimeofday() with >>> ones to __gettimeofday50(). >>> >>> Doing a similar substitution in lisp source may be hard. >> >>We already have some os_foo() wrappers in the runtime for other >>things. Maybe the simplest thing would be to just add one for >>gettimeofday() as well. > >You would need wrappers for quite a few syscalls, I will collect >a list. The list of syscalls that generate a link time warning is: sigreturn() - doesn't exist any more, delete from undefineds for NetBSD ? vfork() - isn't used mknod() - looks to be time, probably don't need in sbcl nanosleep() - time select() - time getitimer() - time setitimer() - time settimeofday() - time, not used wait3() - time, not used utimes() - time, not used mount() - extra argument, probably don't need in sbcl socket() - one error condition changed, probably don't need to wrap gettimeofday() - time getrusage() - time stat() - time, already wrapped fstat() - time, already wrapped lstat() - time, already wrapped readdir() - already wrapped opendir() - already wrapped >From this, it looks to me as if wrappers are needed for nanosleep(), select(), getitimer(), setitimer(), gettimeofday() and getrusage(). The type declarations for the time functions look wrong to me too, Tom Ivar Helbekkmo had already identified this. Also, shouldn't internal-time be a bignum on a 32 bit platform with 64 bit time_t ? It is declared in src/compiler/generic/vm-type.lisp to be unsigned-byte. Robert Swindells |
From: Robert S. <rj...@fd...> - 2013-07-12 14:15:00
|
I have built with this patch. It seems to work on NetBSD/i386 and NetBSD/amd64, not tested on anything else. I don't know why the change to not disassemble sb-sprof::consalot is needed but it just locks up for me if I leave it in. diff --git a/contrib/sb-sprof/test.lisp b/contrib/sb-sprof/test.lisp index 9a16960..286757e 100644 --- a/contrib/sb-sprof/test.lisp +++ b/contrib/sb-sprof/test.lisp @@ -10,4 +10,5 @@ ;; the allocation sequence gets hit in the right places (i.e. not at all ;; in traditional builds, and everywhere if SB-SAFEPOINT-STRICTLY is ;; enabled.) +#-(and netbsd x86) (disassemble #'sb-sprof::consalot) diff --git a/src/code/unix.lisp b/src/code/unix.lisp index 0856069..1f0f562 100644 --- a/src/code/unix.lisp +++ b/src/code/unix.lisp @@ -537,10 +537,10 @@ avoiding atexit(3) hooks, etc. Otherwise exit(2) is called." #!-win32 (defun unix-fast-getrusage (who) (declare (values (member t) - (unsigned-byte 31) (integer 0 1000000) - (unsigned-byte 31) (integer 0 1000000))) + unsigned-byte fixnum + unsigned-byte fixnum)) (with-alien ((usage (struct rusage))) - (syscall* ("getrusage" int (* (struct rusage))) + (syscall* ("sb_getrusage" int (* (struct rusage))) (values t (slot (slot usage 'ru-utime) 'tv-sec) (slot (slot usage 'ru-utime) 'tv-usec) @@ -556,7 +556,7 @@ avoiding atexit(3) hooks, etc. Otherwise exit(2) is called." #!-win32 (defun unix-getrusage (who) (with-alien ((usage (struct rusage))) - (syscall ("getrusage" int (* (struct rusage))) + (syscall ("sb_getrusage" int (* (struct rusage))) (values t (+ (* (slot (slot usage 'ru-utime) 'tv-sec) 1000000) (slot (slot usage 'ru-utime) 'tv-usec)) @@ -654,7 +654,7 @@ avoiding atexit(3) hooks, etc. Otherwise exit(2) is called." (type (or null (unsigned-byte 31)) timeout-secs timeout-usecs)) (with-fd-setsize (num-descriptors) (flet ((select (tv-sap) - (int-syscall ("select" int (* (struct fd-set)) (* (struct fd-set)) + (int-syscall ("sb_select" int (* (struct fd-set)) (* (struct fd-set)) (* (struct fd-set)) (* (struct timeval))) num-descriptors read-fds write-fds exception-fds tv-sap))) @@ -719,7 +719,7 @@ avoiding atexit(3) hooks, etc. Otherwise exit(2) is called." `(if (zerop ,lispvar) (int-sap 0) (alien-sap (addr ,alienvar))))) - (syscall ("select" int (* (struct fd-set)) (* (struct fd-set)) + (syscall ("sb_select" int (* (struct fd-set)) (* (struct fd-set)) (* (struct fd-set)) (* (struct timeval))) (values result (fd-set-to-num nfds rdf) @@ -938,7 +938,7 @@ avoiding atexit(3) hooks, etc. Otherwise exit(2) is called." (slot req 'tv-nsec) nsecs) (loop while (and (eql sb!unix:eintr (nth-value 1 - (int-syscall ("nanosleep" (* (struct timespec)) + (int-syscall ("sb_nanosleep" (* (struct timespec)) (* (struct timespec))) (addr req) (addr rem)))) ;; KLUDGE: On Darwin, if an interrupt cases nanosleep to @@ -1001,14 +1001,14 @@ avoiding atexit(3) hooks, etc. Otherwise exit(2) is called." T, it-interval-secs, it-interval-usec, it-value-secs, it-value-usec." (declare (type (member :real :virtual :profile) which) (values t - (unsigned-byte 29) (mod 1000000) - (unsigned-byte 29) (mod 1000000))) + unsigned-byte (mod 1000000) + unsigned-byte (mod 1000000))) (let ((which (ecase which (:real itimer-real) (:virtual itimer-virtual) (:profile itimer-prof)))) (with-alien ((itv (struct itimerval))) - (syscall* ("getitimer" int (* (struct itimerval))) + (syscall* ("sb_getitimer" int (* (struct itimerval))) (values t (slot (slot itv 'it-interval) 'tv-sec) (slot (slot itv 'it-interval) 'tv-usec) @@ -1027,11 +1027,11 @@ avoiding atexit(3) hooks, etc. Otherwise exit(2) is called." unix-setitimer returns the old contents of the INTERVAL and VALUE slots as in unix-getitimer." (declare (type (member :real :virtual :profile) which) - (type (unsigned-byte 29) int-secs val-secs) + (type unsigned-byte int-secs val-secs) (type (integer 0 (1000000)) int-usec val-usec) (values t - (unsigned-byte 29) (mod 1000000) - (unsigned-byte 29) (mod 1000000))) + unsigned-byte (mod 1000000) + unsigned-byte (mod 1000000))) (let ((which (ecase which (:real itimer-real) (:virtual itimer-virtual) @@ -1042,7 +1042,7 @@ avoiding atexit(3) hooks, etc. Otherwise exit(2) is called." (slot (slot itvn 'it-interval) 'tv-usec) int-usec (slot (slot itvn 'it-value ) 'tv-sec ) val-secs (slot (slot itvn 'it-value ) 'tv-usec) val-usec) - (syscall* ("setitimer" int (* (struct timeval))(* (struct timeval))) + (syscall* ("sb_setitimer" int (* (struct timeval))(* (struct timeval))) (values t (slot (slot itvo 'it-interval) 'tv-sec) (slot (slot itvo 'it-interval) 'tv-usec) @@ -1070,23 +1070,23 @@ avoiding atexit(3) hooks, etc. Otherwise exit(2) is called." (defun get-time-of-day () "Return the number of seconds and microseconds since the beginning of the UNIX epoch (January 1st 1970.)" - #!+darwin + #!+(or darwin netbsd) (with-alien ((tv (struct timeval))) ;; CLH: FIXME! This seems to be a MacOS bug, but on x86-64/darwin, ;; gettimeofday occasionally fails. passing in a null pointer for the ;; timezone struct seems to work around the problem. NS notes: Darwin ;; manpage says the timezone is not used anymore in their implementation ;; at all. - (syscall* ("gettimeofday" (* (struct timeval)) + (syscall* ("sb_gettimeofday" (* (struct timeval)) (* (struct timezone))) (values (slot tv 'tv-sec) (slot tv 'tv-usec)) (addr tv) nil)) - #!-(and x86-64 darwin) + #!-(or darwin netbsd) (with-alien ((tv (struct timeval)) (tz (struct timezone))) - (syscall* ("gettimeofday" (* (struct timeval)) + (syscall* ("sb_gettimeofday" (* (struct timeval)) (* (struct timezone))) (values (slot tv 'tv-sec) (slot tv 'tv-usec)) @@ -1098,7 +1098,7 @@ the UNIX epoch (January 1st 1970.)" (defun system-real-time-values () (multiple-value-bind (sec usec) (get-time-of-day) - (declare (type (unsigned-byte 32) sec usec)) + (declare (type unsigned-byte sec) (type (unsigned-byte 31) usec)) (values sec (truncate usec micro-seconds-per-internal-time-unit)))) ;; There are two optimizations here that actually matter (on 32-bit @@ -1123,7 +1123,7 @@ the UNIX epoch (January 1st 1970.)" (c-sec 0) (c-msec 0) (now 0)) - (declare (type (unsigned-byte 32) e-sec c-sec) + (declare (type unsigned-byte e-sec c-sec) (type fixnum e-msec c-msec) (type unsigned-byte now)) (defun reinit-internal-real-time () @@ -1159,12 +1159,12 @@ the UNIX epoch (January 1st 1970.)" (multiple-value-bind (ignore utime-sec utime-usec stime-sec stime-usec) (unix-fast-getrusage rusage_self) (declare (ignore ignore) - (type (unsigned-byte 31) utime-sec stime-sec) + (type unsigned-byte utime-sec stime-sec) ;; (Classic CMU CL had these (MOD 1000000) instead, but ;; at least in Linux 2.2.12, the type doesn't seem to ;; be documented anywhere and the observed behavior is ;; to sometimes return 1000000 exactly.) - (type (integer 0 1000000) utime-usec stime-usec)) + (type fixnum utime-usec stime-usec)) (let ((result (+ (* (+ utime-sec stime-sec) sb!xc:internal-time-units-per-second) (floor (+ utime-usec diff --git a/src/runtime/wrap.c b/src/runtime/wrap.c index 3f174f3..7c88568 100644 --- a/src/runtime/wrap.c +++ b/src/runtime/wrap.c @@ -38,7 +38,9 @@ #ifndef LISP_FEATURE_WIN32 #include <pwd.h> +#include <time.h> #include <sys/wait.h> +#include <sys/resource.h> #include <netdb.h> #endif #include <stdio.h> @@ -376,7 +378,7 @@ wrapped_environ() * faked-up implementation of select(). Right now just enough to get through * second genesis. */ -int select(int top_fd, DWORD *read_set, DWORD *write_set, DWORD *except_set, time_t *timeout) +int sb_select(int top_fd, DWORD *read_set, DWORD *write_set, DWORD *except_set, time_t *timeout) { /* * FIXME: Going forward, we may want to use MsgWaitForMultipleObjects @@ -425,7 +427,7 @@ int select(int top_fd, DWORD *read_set, DWORD *write_set, DWORD *except_set, tim */ #define UNIX_EPOCH_FILETIME 116444736000000000ULL -int gettimeofday(long *timeval, long *timezone) +int sb_gettimeofday(long *timeval, long *timezone) { FILETIME ft; ULARGE_INTEGER uft; @@ -512,3 +514,37 @@ int s_issock(mode_t mode) #endif } #endif /* !LISP_FEATURE_WIN32 */ + +#ifndef LISP_FEATURE_WIN32 +int sb_getrusage(int who, struct rusage *rusage) +{ + return getrusage(who, rusage); +} + +int sb_gettimeofday(struct timeval *tp, void *tzp) +{ + return gettimeofday(tp, tzp); +} + +int sb_nanosleep(struct timespec *rqtp, struct timespec *rmtp) +{ + return nanosleep(rqtp, rmtp); +} + +int sb_select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, + struct timeval *timeout) +{ + return select(nfds, readfds, writefds, exceptfds, timeout); +} + +int sb_getitimer(int which, struct itimerval *value) +{ + return getitimer(which, value); +} + +int sb_setitimer(int which, struct itimerval *value, struct itimerval *ovalue) +{ + return setitimer(which, value, ovalue); +} +#endif /* !LISP_FEATURE_WIN32 */ + |
From: Tom I. H. <ti...@ha...> - 2013-07-12 20:52:59
|
Robert Swindells <rj...@fd...> writes: > I have built with this patch. > > It seems to work on NetBSD/i386 and NetBSD/amd64, not tested on anything > else. Works fine for me, too, on NetBSD/i386-current. :) > I don't know why the change to not disassemble sb-sprof::consalot is > needed but it just locks up for me if I leave it in. Yeah, same here - I've had it disabled "forever" locally. -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Tom I. H. <ti...@ha...> - 2013-07-13 14:18:10
|
I wrote: > Works fine for me, too, on NetBSD/i386-current. :) ...and on NetBSD/amd64-current. > Robert Swindells <rj...@fd...> writes: > >> I don't know why the change to not disassemble sb-sprof::consalot is >> needed but it just locks up for me if I leave it in. I had to disable that on the amd64 as well, here. -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
From: Robert S. <rj...@fd...> - 2013-07-13 15:14:45
|
Tom Ivar Helbekkmo <ti...@ha...> wrote: > Robert Swindells <rj...@fd...> writes: > >> I don't know why the change to not disassemble sb-sprof::consalot is >> needed but it just locks up for me if I leave it in. >I had to disable that on the amd64 as well, here. It works fine for me on amd64 but I have other local changes for sbcl and build with threads enabled. Robert Swindells |