From: Hannah S. <ha...@sc...> - 2001-05-16 14:02:43
|
[CC sbc...@li... because of the SBCL specific problem] In article <87a...@no...>, Daniel Barlow <da...@te...> wrote: >[...] >Incidentally, the next release of SBCL should include the Alpha >compiler backend (transplanted from CMUCL) and runtime support for >Linux/Alpha. SBCL will no longer be x86-only ... Yes, but as "compensation" it seems that it doesn't work on BSD, especially OpenBSD, anymore. I have 0.6.11.41 running, and newer sources from the CVS fail to compile with that host, especially in the C runtime system. There are problems that the source uses the names "st_mtime" ... in an own structure to map the OS specific struct stat to a common structure, however, on OpenBSD, struct stat contains: ... struct timespec st_atimespec; /* time of last access */ struct timespec st_mtimespec; /* time of last data modification */ struct timespec st_ctimespec; /* time of last file status change */ ... and defines: #define st_atime st_atimespec.tv_sec [...] #define st_mtime st_mtimespec.tv_sec [...] #define st_ctime st_ctimespec.tv_sec src/runtime/wrap.c declares structure members time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ which get expanded to time_t st_atimespec.tv_sec; time_t st_mtimespec.tv_sec; time_t st_ctimespec.tv_sec; which is a syntax error. Once, I tried to fix it and did compile the runtime however got a strange error a bit later when compiling some Lisp file. Perhaps some SBCL person might look into that? Kind regards, Hannah. |
From: William H. N. <wil...@ai...> - 2001-05-17 13:03:50
|
On Wed, May 16, 2001 at 04:02:34PM +0200, Hannah Schroeter wrote: > Yes, but as "compensation" it seems that it doesn't work on BSD, > especially OpenBSD, anymore. (I didn't realize there was another OpenBSD user out there! Welcome!) > I have 0.6.11.41 running, and newer sources from the CVS fail to compile > with that host, especially in the C runtime system. > > There are problems that the source uses the names "st_mtime" ... > in an own structure to map the OS specific struct stat to a common > structure, however, on OpenBSD, struct stat contains: > > ... > struct timespec st_atimespec; /* time of last access */ > struct timespec st_mtimespec; /* time of last data modification */ > struct timespec st_ctimespec; /* time of last file status change */ > ... [etc.] I ran into this OpenBSD problem last week. I made a fix for it, and even checked it into CVS in the "flaky1" branch. It's a slightly unsatisfactory fix, since I left FILE-LENGTH stubbed out for now, but all the other stat stuff, including all the stat stuff that SBCL itself needs, still works. Unfortunately I had some GC problems too, and in trying to fix them seem to have screwed everything up, not only for OpenBSD but for Linux too. Even more unfortunately, in trying to fix those problems I've been bewildered for days. So the "flaky1" changes haven't been merged into the main branch, because then no one, Linux or *BSD, would be able to compile from CVS.:-( Unscrewing this at least for Linux is currently my first SBCL development priority. (Unscrewing it for OpenBSD would be ordinarily be just as high a priority, since I want to develop on my OpenBSD laptop, except that some of the confusion over the last week has been caused by OpenBSD 2.8 kernel crashes, while Linux has remained reliable. At this point I certainly don't need any more confusion, so I'm focusing on Linux.) After that, OpenBSD remains a reasonably high priority. Unfortunately, the problems begun last week have been a rather humbling experience -- it's remarkable how confused I've gotten.. -- and I don't know whether I'll get tripped up by more OpenBSD kernel bugs, so I don't have much of a guess whether the OpenBSD fixes will be done today or this weekend or what. -- William Harold Newman <wil...@ai...> "Tweak alpha so it sends SIGBUS for unaligned access, and does NOT do a fixup. This encourages people to fix their code." -- a commit note from <http://www.OpenBSD.org/plus29.html> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2001-05-22 16:40:50
|
On Thu, May 17, 2001 at 07:57:50AM -0500, William Harold Newman wrote: > On Wed, May 16, 2001 at 04:02:34PM +0200, Hannah Schroeter wrote: > > Yes, but as "compensation" it seems that it doesn't work on BSD, > > especially OpenBSD, anymore. [..] > After that, OpenBSD remains a reasonably high priority. Unfortunately, > the problems begun last week have been a rather humbling experience -- > it's remarkable how confused I've gotten.. -- and I don't know whether > I'll get tripped up by more OpenBSD kernel bugs, so I don't have much > of a guess whether the OpenBSD fixes will be done today or this > weekend or what. I spent some time looking at this yesterday and the day before. I rather expected that I'd be able to see the problem in the diffs between the current version and the last working version if I just looked carefully enough, but no luck. I also panicked OpenBSD again, and this time I got a trace and sent in a bug report. I'll probably continue investigating the problem by trying to learn why the garbage collector is complaining after warm init saves sbcl.core. With luck, I can localize that problem in a manageable region by commenting out more and more of warm init until it goes away, then poke around with gdb or assertions or something to see what's going on. But I don't know how long that will take, or how many hours per day I'll devote to it. OS panics are discouraging.. -- William Harold Newman <wil...@ai...> "As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database." -- http://mindprod.com/unmain.html PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2001-05-27 15:21:30
|
(The original message I'm replying to was on sbcl-help, so I'm posting this there. But I've also talked about this problem on sbcl-devel, so I'm posting it there too.) On Tue, May 22, 2001 at 11:34:16AM -0500, William Harold Newman wrote: > On Thu, May 17, 2001 at 07:57:50AM -0500, William Harold Newman wrote: > > On Wed, May 16, 2001 at 04:02:34PM +0200, Hannah Schroeter wrote: > > > Yes, but as "compensation" it seems that it doesn't work on BSD, > > > especially OpenBSD, anymore. > [..] > > After that, OpenBSD remains a reasonably high priority. Unfortunately, > > the problems begun last week have been a rather humbling experience -- > > it's remarkable how confused I've gotten.. -- and I don't know whether > > I'll get tripped up by more OpenBSD kernel bugs, so I don't have much > > of a guess whether the OpenBSD fixes will be done today or this > > weekend or what. [..] > I'll probably continue investigating the problem by trying to learn > why the garbage collector is complaining after warm init saves > sbcl.core. With luck, I can localize that problem in a manageable > region by commenting out more and more of warm init until it goes > away, then poke around with gdb or assertions or something to see > what's going on. But I don't know how long that will take, or how many > hours per day I'll devote to it. OS panics are discouraging.. sbcl-0.6.12.17, now committed to CVS, works on OpenBSD again, for the first time since the Alpha patches were committed. The necessary fix was to change the memory map, moving the control stack out of its previous address range. The bug was in fact found as suggested above, by figuring out why the GC was complaining after warm init saves sbcl.core. The process was complicated by my attempts to use gdb to do so, which never worked. Eventually I just found it by bisection, rebuilding smaller and smaller subsets of the program in order to find what functionality was required to cause the corruption to occur. (Judging from the behavior of the new trymap utility, the same address space conflict has existed at least since OpenBSD 2.7 (the oldest version I can test conveniently). So it's unclear to me how the pre-Alpha-patches versions of SBCL managed to work, since they all used the same address space mapping.) -- William Harold Newman <wil...@ai...> "The beatings will continue until morale improves." -- ?? PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |