From: Elliott S. <ell...@gm...> - 2008-07-04 23:25:01
|
Hi, This is an update on my attempts to port Alastair Bridgewater's old EBX/win32 threading patch to HEAD. So far most of the merges have been uneventful, although I have a question regarding the use of C preprocessor conditionals. I believe that forms "#ifdef ..." and "#if defined(...)" are functionally equivalent, but the source seems to have an even distribution of both forms and some revisions of the code switch from one form to the other. Is there any reason (other than cosmetic) for preferring one form over the other? Currently, I'm having some issues resolving 1.0.16.31 (--control-stack-size runtime argument), which significantly alters many of the functions in src/runtime/thread.c. The patch adds a number of instances to various pthread types or functions, many of which I am not sure how to deal with. For example, the third hunk of the patch adds pthread_attr_t *os_attr; which I am not sure is relevant or needed in win32 threading (or if it is necessary in win32, how to implement it). Later, in the definition of perform_thread_post_mortem, there is a line containing gc_assert(!pthread_attr_destroy(post_mortem->os_attr)); which I am similarly stumped by. I am tempted to just wrap these and other similar instances with "#ifndef LISP_FEATURE_WIN32" but I am not sure if I need to implement equivalent code for win32 or not. Any insights would be appreciated. Thanks in advance. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Nikodemus S. <nik...@ra...> - 2008-07-05 08:44:24
|
On Sat, Jul 5, 2008 at 2:24 AM, Elliott Slaughter <ell...@gm...> wrote: > which I am similarly stumped by. I am tempted to just wrap these and > other similar instances with "#ifndef LISP_FEATURE_WIN32" but I am not > sure if I need to implement equivalent code for win32 or not. Depends on how thread stacks will work on Windows. The post mortem stuff is there to deal with freeing thread stacks after the thread has exited. You can #ifdef if out for now, and later, when you know if you need it or not, you can deal with it appropriately. As for various pthread_foo functions and types: * In those cases where there is a Windows equivalent (not maybe 1:1, but something sufficiently close) hiding the difference under os_thread_foo functions and types is the right thing. * If there is no Windows equivalent, then those definitions can be empty -- it probably makes the code easier to read in the long run the adding #ifndef LISP_FEATURE_WIN32 around them. * ...the hard case is when there is a Windows equivalent you need to use, but which is sufficiently different from the pthreads version that providing a single interface to both is a non-starter: then you just have work case-by-case. Cheers, -- Nikodemus |
From: Elliott S. <ell...@gm...> - 2008-07-08 05:16:46
|
On Sat, Jul 5, 2008 at 1:44 AM, Nikodemus Siivola <nik...@ra...> wrote: > On Sat, Jul 5, 2008 at 2:24 AM, Elliott Slaughter > <ell...@gm...> wrote: > >> which I am similarly stumped by. I am tempted to just wrap these and >> other similar instances with "#ifndef LISP_FEATURE_WIN32" but I am not >> sure if I need to implement equivalent code for win32 or not. > > Depends on how thread stacks will work on Windows. The post mortem > stuff is there to deal with freeing thread stacks after the thread has > exited. > > You can #ifdef if out for now, and later, when you know if you need it > or not, you can deal with it appropriately. Thanks. Based on your advice I completed the rest of the merge, punting on most of hard problems for now. I have put up my current progress at http://repo.or.cz/w/sbcl/eslaughter.git (so Christophe has something to look at for midterm evaluations ;-). Tomorrow I think I'll try to compiling on Linux first to make sure I haven't made any regressions, then see how far I get on win32 before it breaks. (Quick question: does SBCL compile with threads by default on Linux/x86? Or is there an option I need to pass to make.sh?) -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Christophe R. <cs...@ca...> - 2008-07-08 06:15:34
|
"Elliott Slaughter" <ell...@gm...> writes: > On Sat, Jul 5, 2008 at 1:44 AM, Nikodemus Siivola > <nik...@ra...> wrote: >> On Sat, Jul 5, 2008 at 2:24 AM, Elliott Slaughter >> <ell...@gm...> wrote: >> >>> which I am similarly stumped by. I am tempted to just wrap these and >>> other similar instances with "#ifndef LISP_FEATURE_WIN32" but I am not >>> sure if I need to implement equivalent code for win32 or not. >> >> Depends on how thread stacks will work on Windows. The post mortem >> stuff is there to deal with freeing thread stacks after the thread has >> exited. >> >> You can #ifdef if out for now, and later, when you know if you need it >> or not, you can deal with it appropriately. > > Thanks. Based on your advice I completed the rest of the merge, > punting on most of hard problems for now. I have put up my current > progress at http://repo.or.cz/w/sbcl/eslaughter.git (so Christophe has > something to look at for midterm evaluations ;-). Good-oh. > Tomorrow I think I'll try to compiling on Linux first to make sure I > haven't made any regressions, then see how far I get on win32 before > it breaks. (Quick question: does SBCL compile with threads by default > on Linux/x86? Or is there an option I need to pass to make.sh?) You need to create a file called customize-target-features.lisp in the sbcl source directory, containing something like (lambda (list) (list* :sb-thread list)) (see section 2.2 of the INSTALL file) Best, Christophe |
From: Elliott S. <ell...@gm...> - 2008-07-08 22:01:22
|
On Mon, Jul 7, 2008 at 11:15 PM, Christophe Rhodes <cs...@ca...> wrote: > "Elliott Slaughter" <ell...@gm...> writes: >> Tomorrow I think I'll try to compiling on Linux first to make sure I >> haven't made any regressions, then see how far I get on win32 before >> it breaks. (Quick question: does SBCL compile with threads by default >> on Linux/x86? Or is there an option I need to pass to make.sh?) Ok, I confirmed that my patched copy compiles and passes all tests on Linux/x86 with and without :sb-thread. > You need to create a file called customize-target-features.lisp in the > sbcl source directory, containing something like > (lambda (list) (list* :sb-thread list)) > (see section 2.2 of the INSTALL file) I don't suppose compiling with :sb-thread automatically uses the EBX modifications? Alastair's last transcript of attempting to compile with EBX threading (http://paste.lisp.org/display/38635) suggests that :x86-ebx-threads, :x86-reserve-ebx, and :x86-two-arg-passing-regs should be present in *features*, but I didn't find them to be there when compiling with only :sb-thread. Comments? -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Elliott S. <ell...@gm...> - 2008-07-09 03:10:35
|
Hi again, On Tue, Jul 8, 2008 at 3:01 PM, Elliott Slaughter <ell...@gm...> wrote: > On Mon, Jul 7, 2008 at 11:15 PM, Christophe Rhodes <cs...@ca...> wrote: >> You need to create a file called customize-target-features.lisp in the >> sbcl source directory, containing something like >> (lambda (list) (list* :sb-thread list)) >> (see section 2.2 of the INSTALL file) > > I don't suppose compiling with :sb-thread automatically uses the EBX > modifications? Alastair's last transcript of attempting to compile > with EBX threading (http://paste.lisp.org/display/38635) suggests that > :x86-ebx-threads, :x86-reserve-ebx, and :x86-two-arg-passing-regs > should be present in *features*, but I didn't find them to be there > when compiling with only :sb-thread. Comments? Based on my previous hunch, I tried compiling with :x86-ebx-threads, :x86-reserve-ebx, and :x86-two-arg-passing-regs. Linux compiled and tested fine, although I am starting to have doubts about whether that means anything, since the system was really x86-64, not x86. (And I'm not sure how to do a cross-compile for just plain x86.) On win32, compilation failed (not unexpectedly). I resolved several C compilation errors, which got me past genesis, but upon attempting to load cold-sbcl.core into the new system, something broke and dropped the system into ldb (see below). In case more context is desirable, I have uploaded the entire session to http://blackthorncentral.net/files/sbcl_ebx-win32_build_log.7z . [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 41582592 bytes [10152 pages] from #<SB!FASL::GSPACE :DYNAMIC> /(DESCRIPTOR-BITS INITIAL-FUN)=#XA86E58D done] * //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good real 4m0.453s user 0m0.182s sys 0m0.106s //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.17.39, 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. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" * 10 * 5 * T * *COMPILE-FILES-P* * Argh! corrupted error depth, halting fatal error encountered in SBCL pid 3560(tid 2960): %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Christophe R. <cs...@ca...> - 2008-07-09 13:57:38
|
"Elliott Slaughter" <ell...@gm...> writes: >> I don't suppose compiling with :sb-thread automatically uses the EBX >> modifications? Alastair's last transcript of attempting to compile >> with EBX threading (http://paste.lisp.org/display/38635) suggests that >> :x86-ebx-threads, :x86-reserve-ebx, and :x86-two-arg-passing-regs >> should be present in *features*, but I didn't find them to be there >> when compiling with only :sb-thread. Comments? > > Based on my previous hunch, I tried compiling with :x86-ebx-threads, > :x86-reserve-ebx, and :x86-two-arg-passing-regs. Linux compiled and > tested fine, although I am starting to have doubts about whether that > means anything, since the system was really x86-64, not x86. Right, it doesn't mean anything. > (And I'm not sure how to do a cross-compile for just plain x86.) If you're lucky, then "SBCL_ARCH=x86 ./make.sh" will do it. (Your system might well need a bunch of clever development tools, but I think it can be made to work; you might need to alter paths so that gcc points to the 32-bit one, etc.) Otherwise, install an x86 somewhere, virtualized or physical, or get remote access to one. > On win32, compilation failed (not unexpectedly). I resolved several C > compilation errors, which got me past genesis, but upon attempting to > load cold-sbcl.core into the new system, something broke and dropped > the system into ldb (see below). In case more context is desirable, I > have uploaded the entire session to > http://blackthorncentral.net/files/sbcl_ebx-win32_build_log.7z . > //doing warm init - compilation phase > This is SBCL 1.0.17.39, 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. > > This is experimental prerelease support for the Windows platform: use > at your own risk. "Your Kitten of Death awaits!" > > * > 10 > * > 5 > * > T > * > *COMPILE-FILES-P* OK, so you're running Lisp code successfully, all the way up to warm init of the system; on the other hand, you manage to corrupt the image before or shortly afterwards, such that you don't get a nice friendly debugger when something goes wrong. Allocation can't be completely off, because there's a huge amount of allocation in cold-init. What about GC? What happens if you disable the garbage collector (or rather, don't re-enable it; look for (gc-on) and (gc :full t) in src/code/cold-init.lisp)? One other thing to do is to review the entire patch, carefully, line by line, until you're sure you understand how everything there interacts. Another might be to make sure that the patch as applied to the version of SBCL it was "designed" for works as it used to. Best, Christophe |
From: Elliott S. <ell...@gm...> - 2008-07-10 04:28:51
|
Thanks for all the help :-) On Wed, Jul 9, 2008 at 6:57 AM, Christophe Rhodes <cs...@ca...> wrote: > "Elliott Slaughter" <ell...@gm...> writes: >> (And I'm not sure how to do a cross-compile for just plain x86.) > > If you're lucky, then "SBCL_ARCH=x86 ./make.sh" will do it. Unfortunately without 32-bit gcc this caused many warnings and finally a fatal error in the assembler. > (Your system might well need a bunch of clever development tools, > but I think it can be made to work; you might need to alter paths > so that gcc points to the 32-bit one, etc.) Would you expect an x86_64 Linux system to come with both 64 and 32-bit copies of gcc by default? Looking in /usr/bin/ I can see x86_64-linux-gnu-gcc but no plain x86 version. I could probably compile a cross compiler, but I don't know exactly how much effort would be involved in making that work. > Otherwise, install an x86 somewhere, virtualized or physical, or get > remote access to one. I don't know if I have access to any x86 Linux machines.... I *do* have two free hard drives on my machine so I might be able to run plain x86 on top of my x86_64 machine. (Correct me if I'm not thinking straight.) Anyway, I can't try this until tomorrow after I get broadband internet installed, because a multiple hundred MB download is simply impossible on 56 Kb dial-up. >> On win32, compilation failed (not unexpectedly). I resolved several C >> compilation errors, which got me past genesis, but upon attempting to >> load cold-sbcl.core into the new system, something broke and dropped >> the system into ldb (see below). In case more context is desirable, I >> have uploaded the entire session to >> http://blackthorncentral.net/files/sbcl_ebx-win32_build_log.7z . > >> //doing warm init - compilation phase >> This is SBCL 1.0.17.39, 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. >> >> This is experimental prerelease support for the Windows platform: use >> at your own risk. "Your Kitten of Death awaits!" >> >> * >> 10 >> * >> 5 >> * >> T >> * >> *COMPILE-FILES-P* > > OK, so you're running Lisp code successfully, all the way up to warm > init of the system; on the other hand, you manage to corrupt the image > before or shortly afterwards, such that you don't get a nice friendly > debugger when something goes wrong. Allocation can't be completely > off, because there's a huge amount of allocation in cold-init. What > about GC? What happens if you disable the garbage collector (or > rather, don't re-enable it; look for (gc-on) and (gc :full t) in > src/code/cold-init.lisp)? I commented out both (gc-on) and (gc :full t) and still observed exactly the same crash. > One other thing to do is to review the entire patch, carefully, line > by line, until you're sure you understand how everything there > interacts. Hmm... I agree that my understanding of the code is a bit sketchy right now and could use some strong reinforcement. But I am not sure reading the patch line by line is the best method... it is 78 KB (about 2000 lines) after all. > Another might be to make sure that the patch as applied to > the version of SBCL it was "designed" for works as it used to. Yes, the old patch, when applied to 1.0.3.47 (incidentally, branch ebx-1 in my repo), compiles and runs just fine. (You can even start threads, although it is probably not a good idea to run multiple threads, or generate any garbage.) So the problems I am observing are probably either some conflict with changes introduced after 1.0.3.47, or something I managed to mess up myself. Any other suggestions would be greatly appreciated. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Drew C. <dr...@te...> - 2008-07-10 05:10:52
|
2008/7/9 Elliott Slaughter <ell...@gm...>: > I don't know if I have access to any x86 Linux machines.... I can give you access to a 32bit Xen vps running debian. It's a Xen port, rather than hardware virtualisation, but it should do the trick... i expect SBCL to compile under Xen as well. Drop me an email and we'll get something set up. Cheers, drewc >>> On win32, compilation failed (not unexpectedly). I resolved several C >>> compilation errors, which got me past genesis, but upon attempting to >>> load cold-sbcl.core into the new system, something broke and dropped >>> the system into ldb (see below). In case more context is desirable, I >>> have uploaded the entire session to >>> http://blackthorncentral.net/files/sbcl_ebx-win32_build_log.7z . >> >>> //doing warm init - compilation phase >>> This is SBCL 1.0.17.39, 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. >>> >>> This is experimental prerelease support for the Windows platform: use >>> at your own risk. "Your Kitten of Death awaits!" >>> >>> * >>> 10 >>> * >>> 5 >>> * >>> T >>> * >>> *COMPILE-FILES-P* >> >> OK, so you're running Lisp code successfully, all the way up to warm >> init of the system; on the other hand, you manage to corrupt the image >> before or shortly afterwards, such that you don't get a nice friendly >> debugger when something goes wrong. Allocation can't be completely >> off, because there's a huge amount of allocation in cold-init. What >> about GC? What happens if you disable the garbage collector (or >> rather, don't re-enable it; look for (gc-on) and (gc :full t) in >> src/code/cold-init.lisp)? > > I commented out both (gc-on) and (gc :full t) and still observed > exactly the same crash. > >> One other thing to do is to review the entire patch, carefully, line >> by line, until you're sure you understand how everything there >> interacts. > > Hmm... I agree that my understanding of the code is a bit sketchy > right now and could use some strong reinforcement. But I am not sure > reading the patch line by line is the best method... it is 78 KB > (about 2000 lines) after all. > >> Another might be to make sure that the patch as applied to >> the version of SBCL it was "designed" for works as it used to. > > Yes, the old patch, when applied to 1.0.3.47 (incidentally, branch > ebx-1 in my repo), compiles and runs just fine. (You can even start > threads, although it is probably not a good idea to run multiple > threads, or generate any garbage.) So the problems I am observing are > probably either some conflict with changes introduced after 1.0.3.47, > or something I managed to mess up myself. > > Any other suggestions would be greatly appreciated. > > > -- > Elliott Slaughter > > "Any road followed precisely to its end leads precisely nowhere." - > Frank Herbert > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: F. <fa...@gm...> - 2008-07-10 12:02:16
|
1- assuming you have 32-bit libraries installed, you can compile simple things on a 64-bit system with CC="gcc -m32" or CFLAGS="-m32 -O2" or something like that. 2- you can trivially install a 32-bit debian (or redhat, etc.) system on your 64-bit machine and use it using chroot, dchroot, etc. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I contend we are both atheists, I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. -- Stephen F Roberts 2008/7/10 Elliott Slaughter <ell...@gm...>: > Thanks for all the help :-) > > On Wed, Jul 9, 2008 at 6:57 AM, Christophe Rhodes <cs...@ca...> wrote: >> "Elliott Slaughter" <ell...@gm...> writes: >>> (And I'm not sure how to do a cross-compile for just plain x86.) >> >> If you're lucky, then "SBCL_ARCH=x86 ./make.sh" will do it. > > Unfortunately without 32-bit gcc this caused many warnings and finally > a fatal error in the assembler. > >> (Your system might well need a bunch of clever development tools, >> but I think it can be made to work; you might need to alter paths >> so that gcc points to the 32-bit one, etc.) > > Would you expect an x86_64 Linux system to come with both 64 and > 32-bit copies of gcc by default? Looking in /usr/bin/ I can see > x86_64-linux-gnu-gcc but no plain x86 version. I could probably > compile a cross compiler, but I don't know exactly how much effort > would be involved in making that work. > >> Otherwise, install an x86 somewhere, virtualized or physical, or get >> remote access to one. > > I don't know if I have access to any x86 Linux machines.... I *do* > have two free hard drives on my machine so I might be able to run > plain x86 on top of my x86_64 machine. (Correct me if I'm not thinking > straight.) Anyway, I can't try this until tomorrow after I get > broadband internet installed, because a multiple hundred MB download > is simply impossible on 56 Kb dial-up. > >>> On win32, compilation failed (not unexpectedly). I resolved several C >>> compilation errors, which got me past genesis, but upon attempting to >>> load cold-sbcl.core into the new system, something broke and dropped >>> the system into ldb (see below). In case more context is desirable, I >>> have uploaded the entire session to >>> http://blackthorncentral.net/files/sbcl_ebx-win32_build_log.7z . >> >>> //doing warm init - compilation phase >>> This is SBCL 1.0.17.39, 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. >>> >>> This is experimental prerelease support for the Windows platform: use >>> at your own risk. "Your Kitten of Death awaits!" >>> >>> * >>> 10 >>> * >>> 5 >>> * >>> T >>> * >>> *COMPILE-FILES-P* >> >> OK, so you're running Lisp code successfully, all the way up to warm >> init of the system; on the other hand, you manage to corrupt the image >> before or shortly afterwards, such that you don't get a nice friendly >> debugger when something goes wrong. Allocation can't be completely >> off, because there's a huge amount of allocation in cold-init. What >> about GC? What happens if you disable the garbage collector (or >> rather, don't re-enable it; look for (gc-on) and (gc :full t) in >> src/code/cold-init.lisp)? > > I commented out both (gc-on) and (gc :full t) and still observed > exactly the same crash. > >> One other thing to do is to review the entire patch, carefully, line >> by line, until you're sure you understand how everything there >> interacts. > > Hmm... I agree that my understanding of the code is a bit sketchy > right now and could use some strong reinforcement. But I am not sure > reading the patch line by line is the best method... it is 78 KB > (about 2000 lines) after all. > >> Another might be to make sure that the patch as applied to >> the version of SBCL it was "designed" for works as it used to. > > Yes, the old patch, when applied to 1.0.3.47 (incidentally, branch > ebx-1 in my repo), compiles and runs just fine. (You can even start > threads, although it is probably not a good idea to run multiple > threads, or generate any garbage.) So the problems I am observing are > probably either some conflict with changes introduced after 1.0.3.47, > or something I managed to mess up myself. > > Any other suggestions would be greatly appreciated. > > > -- > Elliott Slaughter > > "Any road followed precisely to its end leads precisely nowhere." - > Frank Herbert > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Elliott S. <ell...@gm...> - 2008-07-11 04:00:35
|
On Thu, Jul 10, 2008 at 5:02 AM, Faré <fa...@gm...> wrote: > > 1- assuming you have 32-bit libraries installed, you can compile > simple things on a 64-bit system with CC="gcc -m32" or CFLAGS="-m32 > -O2" or something like that. Unfortunately it doesn't look like my system have 32-bit libraries installed because it couldn't find /usr/include/gnu/stubs-32.h :-( > 2- you can trivially install a 32-bit debian (or redhat, etc.) system > on your 64-bit machine and use it using chroot, dchroot, etc. Actually, I just remembered that UCSD runs its Linux servers on i386 Redhat Linux. I had to install things in unusual places (since I don't have access to the normal locations), but I managed to compile with x86 EBX threads. That said, the run-tests.sh seem to fail when attempting to test thread support, so obviously not everything works smoothly... but hopefully Alastair Bridgewater's updated patch should fix that. (Making this test obsolete, but at least now I have a procedure for testing on Linux/x86.) > [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] > I contend we are both atheists, I just believe in one fewer god than you do. > When you understand why you dismiss all the other possible gods, you will > understand why I dismiss yours. -- Stephen F Roberts > > > 2008/7/10 Elliott Slaughter <ell...@gm...>: > > Thanks for all the help :-) > > > > On Wed, Jul 9, 2008 at 6:57 AM, Christophe Rhodes <cs...@ca...> wrote: > >> "Elliott Slaughter" <ell...@gm...> writes: > >>> (And I'm not sure how to do a cross-compile for just plain x86.) > >> > >> If you're lucky, then "SBCL_ARCH=x86 ./make.sh" will do it. > > > > Unfortunately without 32-bit gcc this caused many warnings and finally > > a fatal error in the assembler. > > > >> (Your system might well need a bunch of clever development tools, > >> but I think it can be made to work; you might need to alter paths > >> so that gcc points to the 32-bit one, etc.) > > > > Would you expect an x86_64 Linux system to come with both 64 and > > 32-bit copies of gcc by default? Looking in /usr/bin/ I can see > > x86_64-linux-gnu-gcc but no plain x86 version. I could probably > > compile a cross compiler, but I don't know exactly how much effort > > would be involved in making that work. > > > >> Otherwise, install an x86 somewhere, virtualized or physical, or get > >> remote access to one. > > > > I don't know if I have access to any x86 Linux machines.... I *do* > > have two free hard drives on my machine so I might be able to run > > plain x86 on top of my x86_64 machine. (Correct me if I'm not thinking > > straight.) Anyway, I can't try this until tomorrow after I get > > broadband internet installed, because a multiple hundred MB download > > is simply impossible on 56 Kb dial-up. > > > >>> On win32, compilation failed (not unexpectedly). I resolved several C > >>> compilation errors, which got me past genesis, but upon attempting to > >>> load cold-sbcl.core into the new system, something broke and dropped > >>> the system into ldb (see below). In case more context is desirable, I > >>> have uploaded the entire session to > >>> http://blackthorncentral.net/files/sbcl_ebx-win32_build_log.7z . > >> > >>> //doing warm init - compilation phase > >>> This is SBCL 1.0.17.39, 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. > >>> > >>> This is experimental prerelease support for the Windows platform: use > >>> at your own risk. "Your Kitten of Death awaits!" > >>> > >>> * > >>> 10 > >>> * > >>> 5 > >>> * > >>> T > >>> * > >>> *COMPILE-FILES-P* > >> > >> OK, so you're running Lisp code successfully, all the way up to warm > >> init of the system; on the other hand, you manage to corrupt the image > >> before or shortly afterwards, such that you don't get a nice friendly > >> debugger when something goes wrong. Allocation can't be completely > >> off, because there's a huge amount of allocation in cold-init. What > >> about GC? What happens if you disable the garbage collector (or > >> rather, don't re-enable it; look for (gc-on) and (gc :full t) in > >> src/code/cold-init.lisp)? > > > > I commented out both (gc-on) and (gc :full t) and still observed > > exactly the same crash. > > > >> One other thing to do is to review the entire patch, carefully, line > >> by line, until you're sure you understand how everything there > >> interacts. > > > > Hmm... I agree that my understanding of the code is a bit sketchy > > right now and could use some strong reinforcement. But I am not sure > > reading the patch line by line is the best method... it is 78 KB > > (about 2000 lines) after all. > > > >> Another might be to make sure that the patch as applied to > >> the version of SBCL it was "designed" for works as it used to. > > > > Yes, the old patch, when applied to 1.0.3.47 (incidentally, branch > > ebx-1 in my repo), compiles and runs just fine. (You can even start > > threads, although it is probably not a good idea to run multiple > > threads, or generate any garbage.) So the problems I am observing are > > probably either some conflict with changes introduced after 1.0.3.47, > > or something I managed to mess up myself. > > > > Any other suggestions would be greatly appreciated. > > > > > > -- > > Elliott Slaughter > > > > "Any road followed precisely to its end leads precisely nowhere." - > > Frank Herbert > > > > ------------------------------------------------------------------------- > > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > > Studies have shown that voting for your favorite open source project, > > along with a healthy diet, reduces your potential for chronic lameness > > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > _______________________________________________ > > Sbcl-devel mailing list > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Alastair B. <nye...@li...> - 2008-07-10 19:51:46
|
Christophe Rhodes wrote: > "Elliott Slaughter" <ell...@gm...> writes: [ snip ] >> On win32, compilation failed (not unexpectedly). I resolved several C >> compilation errors, which got me past genesis, but upon attempting to >> load cold-sbcl.core into the new system, something broke and dropped >> the system into ldb (see below). In case more context is desirable, I >> have uploaded the entire session to >> http://blackthorncentral.net/files/sbcl_ebx-win32_build_log.7z . [ snip ] > One other thing to do is to review the entire patch, carefully, line > by line, until you're sure you understand how everything there > interacts. Another might be to make sure that the patch as applied to > the version of SBCL it was "designed" for works as it used to. I think it's time I weighed in on this thread. I spent a little time recently on the non-win32 version of the ebx-threading patch set, bringing it mostly up to date with 1.0.18. The patches are now available at http://www.lisphacker.com/temp/sbcl-ebx-threads-2/ and "work"... Except that once the last patch is applied and all of the appropriate features enabled, sb-cover and sb-introspect fail to build. The resulting sbcl, however, is capable of building itself again. I haven't taken the time to try and track down why the contribs are failing, nor have I gone back to check to see if they failed with the original patch set. If you decide to start from these patches instead of where you were working from, you should be able to convert the combined ebx-threads / win32-threads patch file into an incremental patch with just the changes from ebx-threads to win32-threads, which should make things easier once you have the ebx-threads stuff stable on linux. From what I remember, it's mostly src/runtime changes anyway. > Best, > > Christophe -- Alastair Bridgewater |
From: Elliott S. <ell...@gm...> - 2008-07-11 04:53:58
|
On Thu, Jul 10, 2008 at 12:50 PM, Alastair Bridgewater <nye...@li...> wrote: > I think it's time I weighed in on this thread. I spent a little time > recently on the non-win32 version of the ebx-threading patch set, bringing > it mostly up to date with 1.0.18. The patches are now available at > http://www.lisphacker.com/temp/sbcl-ebx-threads-2/ and "work"... Except that > once the last patch is applied and all of the appropriate features enabled, > sb-cover and sb-introspect fail to build. The resulting sbcl, however, is > capable of building itself again. I haven't taken the time to try and track > down why the contribs are failing, nor have I gone back to check to see if > they failed with the original patch set. Thanks for the updated patches! When I tried compiling with your wthread-combined-1a.diff, all contribs seemed to build properly, although run-tests.sh did freeze in testing threads (but this is probably an error I added in trying to forward port the old patch to HEAD). > If you decide to start from these patches instead of where you were working > from, you should be able to convert the combined ebx-threads / win32-threads > patch file into an incremental patch with just the changes from ebx-threads > to win32-threads, which should make things easier once you have the > ebx-threads stuff stable on linux. From what I remember, it's mostly > src/runtime changes anyway. How exactly do you propose I go about that? My first idea was to apply wthread-combined-1a.diff to one copy of the 1.0.3.47 tree, and the patches at http://www.lisphacker.com/temp/sbcl-ebx-threads/ to another, and then diff the two trees to get a patch... but then I noticed that those patch files were based on 0.9.12, and didn't apply nicely to 1.0.3.47. I couldn't find any set of separate patches for 1.0.3.47 on your site, so my second idea was to go through wthread-combined-1a.diff and cut out anything that appeared to be dealt with in one of your updated patches, then forward port just the win32 threads portion to 1.0.18. I gave it a try (as far as cutting out the EBX threads stuff), and am reasonably satisfied with the results. So I guess next I'll work on forwarding my work up to 1.0.18 and making a patch based on your new set. If I'm lucky this will help me avoid the errors I was encountering earlier, if not, I'll be back to debugging that later. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Elliott S. <ell...@gm...> - 2008-07-21 23:44:22
|
On Thu, Jul 10, 2008 at 12:50 PM, Alastair Bridgewater <nye...@li...> wrote: > Christophe Rhodes wrote: > I spent a little time recently on the non-win32 version of the ebx-threading patch set, > bringing it mostly up to date with 1.0.18. The patches are now available at > http://www.lisphacker.com/temp/sbcl-ebx-threads-2/ and "work"... Except that > once the last patch is applied and all of the appropriate features enabled, > sb-cover and sb-introspect fail to build. The resulting sbcl, however, is > capable of building itself again. I haven't taken the time to try and track > down why the contribs are failing, nor have I gone back to check to see if > they failed with the original patch set. Are you sure this works on win32? I tried compiling 1.0.18 with your patches today (and features :x86-two-arg-passing-regs and :x86-reserve-ebx), and ran into errors similar to what encountered in my own forward-ported version of the old patch. The error seemed to occur at the beginning of warm init (because of some failure in cold init): //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.18, 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. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" Argh! error in cold init, halting fatal error encountered in SBCL pid 3732: %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> unknown command: ``;;;'' ldb> unknown command: ``;;;'' ldb> unknown command: ``#+sb-show'' ldb> ldb> unknown command: ``;;;'' ldb> unknown command: ``;;;'' ldb> unknown command: ``;;;'' ldb> unknown command: ``;;;'' ldb> unknown command: ``;;;'' ldb> unknown command: ``(setq'' ldb> unknown command: ``(setq'' ldb> unknown command: ``(setq'' ldb> ldb> unknown command: ``;;;'' ldb> unknown command: ``(defvar'' ldb> unknown command: ``#+sb-show'' ldb> unknown command: ``(load'' ldb> This was compiled from a copy of git://repo.or.cz/sbcl/eslaughter.git on the branch ebx_1.0.18 . I can upload the full transcript of the build if that would be helpful. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Elliott S. <ell...@gm...> - 2008-07-25 01:44:10
|
On Mon, Jul 21, 2008 at 4:44 PM, Elliott Slaughter <ell...@gm...> wrote: > > On Thu, Jul 10, 2008 at 12:50 PM, Alastair Bridgewater > <nye...@li...> wrote: > > I spent a little time recently on the non-win32 version of the ebx-threading patch set, > > bringing it mostly up to date with 1.0.18. The patches are now available at > > http://www.lisphacker.com/temp/sbcl-ebx-threads-2/ and "work"... Except that > > once the last patch is applied and all of the appropriate features enabled, > > sb-cover and sb-introspect fail to build. The resulting sbcl, however, is > > capable of building itself again. I haven't taken the time to try and track > > down why the contribs are failing, nor have I gone back to check to see if > > they failed with the original patch set. > > Are you sure this works on win32? I tried compiling 1.0.18 with your > patches today (and features :x86-two-arg-passing-regs and > :x86-reserve-ebx), and ran into errors similar to what encountered in > my own forward-ported version of the old patch. The error seemed to > occur at the beginning of warm init (because of some failure in cold > init): Ok, I compiled with the updated patches on Linux and got the same result as you, so at least we are somewhat on the same page. Unfortunately, win32 still fails under the updated patches. I did several incremental compiles, adding the patches one at a time, to see where the patches start having problems. Up to patch 3 compiles fine, but patch 4 fails 15 contrib modules (which may be all of them, as I don't know how many there are), and by patch 5 I get the same crash to ldb right after cold init as I have seen twice before. I suppose I'll start looking at patches 3 and 4 in detail, to try and find exactly what is going wrong. As always, suggestions/advice would be appreciated. (A fix from Alastair would be even better, but I don't how busy you are, so I'll try to tack a whack at it first :-) -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Alastair B. <nye...@li...> - 2008-07-25 02:25:40
|
Elliott Slaughter wrote: > > Ok, I compiled with the updated patches on Linux and got the same > result as you, so at least we are somewhat on the same page. > > Unfortunately, win32 still fails under the updated patches. I did > several incremental compiles, adding the patches one at a time, to see > where the patches start having problems. Up to patch 3 compiles fine, > but patch 4 fails 15 contrib modules (which may be all of them, as I > don't know how many there are), and by patch 5 I get the same crash to > ldb right after cold init as I have seen twice before. > > I suppose I'll start looking at patches 3 and 4 in detail, to try and > find exactly what is going wrong. As always, suggestions/advice would > be appreciated. (A fix from Alastair would be even better, but I don't > how busy you are, so I'll try to tack a whack at it first :-) Did a quick bit of review. Patch 4 appears to be doing things with register choice for the actual calling convention. My best guess there is stale contrib fasls in the build tree. Patch 5 is entirely throw / continue-unwind NLX junk, and should be fairly straightforward to fix. Just (ILTWIS"J") compare the Win32 and non-Win32 cases for THROW and CONTINUE-UNWIND in src/assembly/x86/assem-rtns.lisp and you should see the changes to the register convention. Best of luck, > -- > Elliott Slaughter -- Alastair Bridgewater |
From: Elliott S. <ell...@gm...> - 2008-07-28 20:53:46
|
On Thu, Jul 24, 2008 at 7:24 PM, Alastair Bridgewater <nye...@li...> wrote: > Elliott Slaughter wrote: >> >> Unfortunately, win32 still fails under the updated patches. I did >> several incremental compiles, adding the patches one at a time, to see >> where the patches start having problems. Up to patch 3 compiles fine, >> but patch 4 fails 15 contrib modules (which may be all of them, as I >> don't know how many there are), and by patch 5 I get the same crash to >> ldb right after cold init as I have seen twice before. > > Did a quick bit of review. Patch 4 appears to be doing things with register > choice for the actual calling convention. My best guess there is stale > contrib fasls in the build tree. Patch 5 is entirely throw / continue-unwind > NLX junk, and should be fairly straightforward to fix. Just (ILTWIS"J") > compare the Win32 and non-Win32 cases for THROW and CONTINUE-UNWIND in > src/assembly/x86/assem-rtns.lisp and you should see the changes to the > register convention. Thanks for the information. I'll try to wrap my head around the patches and see if I can find what causes the errors. I don't think the failure at patch 4 is from stale fasls; I used a fresh copy of the source directory every time. (And just to be sure I did it again from a fresh directory and got exactly the same results.) P.S. And what do you mean by 'ILTWIS"J"'? -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Elliott S. <ell...@gm...> - 2008-07-31 22:45:45
|
On Mon, Jul 28, 2008 at 1:53 PM, Elliott Slaughter <ell...@gm...> wrote: > On Thu, Jul 24, 2008 at 7:24 PM, Alastair Bridgewater > <nye...@li...> wrote: >> Elliott Slaughter wrote: >>> >>> Unfortunately, win32 still fails under the updated patches. I did >>> several incremental compiles, adding the patches one at a time, to see >>> where the patches start having problems. Up to patch 3 compiles fine, >>> but patch 4 fails 15 contrib modules (which may be all of them, as I >>> don't know how many there are), and by patch 5 I get the same crash to >>> ldb right after cold init as I have seen twice before. >> >> Did a quick bit of review. Patch 4 appears to be doing things with register >> choice for the actual calling convention. My best guess there is stale >> contrib fasls in the build tree. Patch 5 is entirely throw / continue-unwind >> NLX junk, and should be fairly straightforward to fix. Just (ILTWIS"J") >> compare the Win32 and non-Win32 cases for THROW and CONTINUE-UNWIND in >> src/assembly/x86/assem-rtns.lisp and you should see the changes to the >> register convention. > > Thanks for the information. I'll try to wrap my head around the > patches and see if I can find what causes the errors. I still have no idea what might be wrong with patch 4, but I made an attempt at making the appropriate fixes to patch 5 for win32. With the changes to patch 5 listed below, it failed to compile in about the same place as last time, but instead of crashing to ldb immediately at the start of warm init, it got a little ways before stopping with no error message at all. (The total lack of any error message surprised me enough that I made a fresh copy and compiled again to confirm the results.) diff --git a/src/assembly/x86/assem-rtns.lisp b/src/assembly/x86/assem-rtns.lisp index 9a1713a..760b6c5 100644 --- a/src/assembly/x86/assem-rtns.lisp +++ b/src/assembly/x86/assem-rtns.lisp @@ -313,7 +313,7 @@ (:return-style :none) (:policy :fast-safe)) ((:arg block (any-reg descriptor-reg) eax-offset) - (:arg start (any-reg descriptor-reg) ebx-offset) + (:arg start (any-reg descriptor-reg) #!-x86-reserve-ebx ebx-offset #!+x86-reserve-ebx esi-offset) (:arg count (any-reg descriptor-reg) ecx-offset)) (declare (ignore start count)) This is basically the same change as in the wthread-combined-1a.diff patch for 1.0.3.47. (Since it seemed that non-win32 portion of the patch for unwind was the same in the 1.0.18 version as 1.0.3.47, I assumed the same would work for the win32. I may have been wrong.) One thing that confuses me about patch 5 is why the register choice makes such a difference when the variable is declared ignored anyways. (It would probably help to become more familiar with define-assembly-routine in general.) Here follows the end of transcript from attempting to compile with the above patch. //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.18, 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. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" * 10 * 5 * T * *COMPILE-FILES-P* * ; compiling file "C:\\Bin\\MSYS1.0\\sbcl_attempt_ebx_05_mod_1_2\\src\\PCL\\EARLY-LOW.LISP" (written 31 JUL 2008 03:06:26 PM): ; compiling (IN-PACKAGE "SB-PCL") ; compiling (/SHOW "starting early-low.lisp") ; compiling (DEFVAR *PCL-PACKAGE* ...) ; compiling (DECLAIM (INLINE DEFSTRUCT-CLASSOID-P)) ; compiling (DEFUN DEFSTRUCT-CLASSOID-P ...) ; compiling (DEFUN STRUCTURE-TYPE-P ...) ; compiling (DEFUN FORMAT-SYMBOL ...) ; compiling (DEFUN MAKE-CLASS-SYMBOL ...) ; compiling (DEFUN MAKE-WRAPPER-SYMBOL ...) ; compiling (DEFUN CONDITION-TYPE-P ...) ; compiling (DECLAIM (SPECIAL *THE-CLASS-T* ...)) It just ends abruptly at this point. If any part of this failure holds special significance, I would appreciate an explanation. Thanks. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Elliott S. <ell...@gm...> - 2008-08-12 02:46:33
|
On Thu, Jul 31, 2008 at 3:45 PM, Elliott Slaughter <ell...@gm...> wrote: > On Mon, Jul 28, 2008 at 1:53 PM, Elliott Slaughter > <ell...@gm...> wrote: >> On Thu, Jul 24, 2008 at 7:24 PM, Alastair Bridgewater >> <nye...@li...> wrote: >>> Elliott Slaughter wrote: >>>> >>>> Unfortunately, win32 still fails under the updated patches. I did >>>> several incremental compiles, adding the patches one at a time, to see >>>> where the patches start having problems. Up to patch 3 compiles fine, >>>> but patch 4 fails 15 contrib modules (which may be all of them, as I >>>> don't know how many there are), and by patch 5 I get the same crash to >>>> ldb right after cold init as I have seen twice before. >>> >>> Did a quick bit of review. Patch 4 appears to be doing things with register >>> choice for the actual calling convention. My best guess there is stale >>> contrib fasls in the build tree. Patch 5 is entirely throw / continue-unwind >>> NLX junk, and should be fairly straightforward to fix. Just (ILTWIS"J") >>> compare the Win32 and non-Win32 cases for THROW and CONTINUE-UNWIND in >>> src/assembly/x86/assem-rtns.lisp and you should see the changes to the >>> register convention. >> >> Thanks for the information. I'll try to wrap my head around the >> patches and see if I can find what causes the errors. > > This is basically the same change as in the wthread-combined-1a.diff > patch for 1.0.3.47. (Since it seemed that non-win32 portion of the > patch for unwind was the same in the 1.0.18 version as 1.0.3.47, I > assumed the same would work for the win32. I may have been wrong.) I have returned from vacation and am back to work. Looking over wthread-combined-1a.diff again, I missed some important changes to assem-rtns.lisp. With the following patch applied after Alastair's patches up to 05-1.0.18-x86-reserve-ebx-5.patch, I have managed to make SBCL compile properly on win32 again (with all expected contrib modules as well). Next I'll be onto trying to make the ebx-threads/win32-threads portions of the patches work again on win32.... diff --git a/src/assembly/x86/assem-rtns.lisp b/src/assembly/x86/assem-rtns.lisp index 9a1713a..31ab5d7 100644 --- a/src/assembly/x86/assem-rtns.lisp +++ b/src/assembly/x86/assem-rtns.lisp @@ -22,6 +22,7 @@ (return-multiple (:return-style :none)) (;; These four are really arguments. (:temp eax unsigned-reg eax-offset) + #!-x86-reserve-ebx (:temp ebx unsigned-reg ebx-offset) (:temp ecx unsigned-reg ecx-offset) (:temp esi unsigned-reg esi-offset) @@ -313,7 +314,7 @@ (:return-style :none) (:policy :fast-safe)) ((:arg block (any-reg descriptor-reg) eax-offset) - (:arg start (any-reg descriptor-reg) ebx-offset) + (:arg start (any-reg descriptor-reg) #!-x86-reserve-ebx ebx-offset #!+x86-reserve-ebx esi-offset) (:arg count (any-reg descriptor-reg) ecx-offset)) (declare (ignore start count)) @@ -448,8 +449,8 @@ n-word-bytes)))) ;; Update *CURRENT-UNWIND-PROTECT-BLOCK*. - (loadw ebx-tn block unwind-block-current-uwp-slot) - (store-tl-symbol-value ebx-tn *current-unwind-protect-block* ecx-tn) + (loadw edx-tn block unwind-block-current-uwp-slot) + (store-tl-symbol-value edx-tn *current-unwind-protect-block* ecx-tn) ;; Uwp-entry expects some things in known locations so that they can ;; be saved on the stack: the block in edx-tn, start in ebx-tn, and @@ -457,9 +458,9 @@ ;; do need to have access to our own stack frame, so we hijack the ;; known locations to cover our own state. - (inst xor ebx-tn ebx-tn) + (inst xor edx-tn edx-tn) (inst xor ecx-tn ecx-tn) - (inst mov ebx-tn ebp-tn) + (inst mov #!-x86-reserve-ebx ebx-tn #!+x86-reserve-ebx esi-tn ebp-tn) (loadw ebp-tn block unwind-block-current-cont-slot) (inst jmp (make-ea-for-object-slot block unwind-block-entry-pc-slot 0))) @@ -469,7 +470,7 @@ (:translate %continue-unwind) (:policy :fast-safe)) ((:arg block (any-reg descriptor-reg) eax-offset) - (:arg start (any-reg descriptor-reg) ebx-offset) + (:arg start (any-reg descriptor-reg) #!-x86-reserve-ebx ebx-offset #!+x86-reserve-ebx esi-offset) (:arg count (any-reg descriptor-reg) ecx-offset)) (declare (ignore block count)) ;; The args here are mostly ignored because we're using the -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Elliott S. <ell...@gm...> - 2008-08-14 20:59:14
|
On Mon, Aug 11, 2008 at 7:46 PM, Elliott Slaughter <ell...@gm...> wrote: > > Next I'll be onto trying to make the ebx-threads/win32-threads > portions of the patches work again on win32.... While working on getting win32 threading to work, I stumbled across a fix which makes Alastair's 1.0.18 patches compile on Linux/x86 with all contrib modules again (although there might still be problems in run-tests.sh). diff --git a/src/compiler/x86/call.lisp b/src/compiler/x86/call.lisp index 0f2b034..a7e0356 100644 --- a/src/compiler/x86/call.lisp +++ b/src/compiler/x86/call.lisp @@ -1500,8 +1500,10 @@ ;; register on -SB-THREAD. #!+sb-thread (progn + #!-x86-ebx-threads (inst fs-segment-prefix) (inst cmp (make-ea :dword + #!+x86-ebx-threads :base #!+x86-ebx-threads ebx-tn :disp (* thread-stepping-slot n-word-bytes)) nil-value)) #!-sb-thread -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Elliott S. <ell...@gm...> - 2008-08-14 21:16:00
|
On Mon, Aug 11, 2008 at 7:46 PM, Elliott Slaughter <ell...@gm...> wrote: > > Next I'll be onto trying to make the ebx-threads/win32-threads > portions of the patches work again on win32.... I made an attempt at adding win32 threads on top of the working ebx threads patches, which I have put in the ebx-win32_1.0.18 branch of my repository. Unfortunately, compilation fails around warm init, again... (error message included below). I'm mostly out of ideas on how to debug this, so any suggestions for resolving the problem would be appreciated. //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.18, 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. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" Exception Code: 0xc0000005. Faulting IP: 0x412cb0. page status: 0x10000. Was writing: 0, where: 0x3fff8010. fatal error encountered in SBCL pid 2304(tid 3948): Exception too early in cold init, cannot continue. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> unknown command: ``;;;'' [...] -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Brian M. <br...@ma...> - 2008-08-14 21:32:39
|
It doesn't look like cold boot is completing here, so the best step would be to turn on SB-SHOW and watch the messages fly by to get an idea where the problem is. You can add more /show calls if you're blowing up in the middle of a Lisp function. (Yay printf debugging!) Rather than running make-target-2.sh, just run src/runtime/sbcl --core output/cold-sbcl.core This is a lot easier than running make-target-2.sh and having a whole lot of stuff be invoked... once you debug the failure to cold boot you can feed forms from the target-2 build at the REPL for more controlled progress. Brian Elliott Slaughter wrote: > On Mon, Aug 11, 2008 at 7:46 PM, Elliott Slaughter > <ell...@gm...> wrote: > >> Next I'll be onto trying to make the ebx-threads/win32-threads >> portions of the patches work again on win32.... >> > > I made an attempt at adding win32 threads on top of the working ebx > threads patches, which I have put in the ebx-win32_1.0.18 branch of my > repository. Unfortunately, compilation fails around warm init, > again... (error message included below). > > I'm mostly out of ideas on how to debug this, so any suggestions for > resolving the problem would be appreciated. > > //entering make-target-2.sh > //doing warm init - compilation phase > This is SBCL 1.0.18, 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. > > This is experimental prerelease support for the Windows platform: use > at your own risk. "Your Kitten of Death awaits!" > Exception Code: 0xc0000005. > Faulting IP: 0x412cb0. > page status: 0x10000. > Was writing: 0, where: 0x3fff8010. > fatal error encountered in SBCL pid 2304(tid 3948): > Exception too early in cold init, cannot continue. > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> unknown command: ``;;;'' > [...] > > -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |
From: Elliott S. <ell...@gm...> - 2008-08-15 18:52:45
|
Hi, On Thu, Aug 14, 2008 at 2:32 PM, Brian Mastenbrook <br...@ma...> wrote: > It doesn't look like cold boot is completing here, so the best step would be > to turn on SB-SHOW and watch the messages fly by to get an idea where the > problem is. You can add more /show calls if you're blowing up in the middle > of a Lisp function. (Yay printf debugging!) > > Rather than running make-target-2.sh, just run src/runtime/sbcl --core > output/cold-sbcl.core Thanks for the suggestions. Is this normal? It looks a bit strange to me... beginning GENESIS, creating core "output/cold-sbcl.core" /load-cold-foreign-symbol-table FILENAME="src/runtime/sbcl.nm" [...] /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4275232 WARNING: redefining ".text" from #X413C20 to #X409650 /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4232784 WARNING: redefining ".text" from #X409650 to #X413C70 /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4275312 WARNING: redefining ".text" from #X413C70 to #X406ED0 /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4222672 WARNING: redefining ".text" from #X406ED0 to #X413EC0 [...] This repeats several hundred times, for various tags. > This is a lot easier than running make-target-2.sh and having a whole lot of > stuff be invoked... once you debug the failure to cold boot you can feed > forms from the target-2 build at the REPL for more controlled progress. > > Brian > > Elliott Slaughter wrote: > > On Mon, Aug 11, 2008 at 7:46 PM, Elliott Slaughter > <ell...@gm...> wrote: > > > Next I'll be onto trying to make the ebx-threads/win32-threads > portions of the patches work again on win32.... > > > I made an attempt at adding win32 threads on top of the working ebx > threads patches, which I have put in the ebx-win32_1.0.18 branch of my > repository. Unfortunately, compilation fails around warm init, > again... (error message included below). > > I'm mostly out of ideas on how to debug this, so any suggestions for > resolving the problem would be appreciated. > > //entering make-target-2.sh > //doing warm init - compilation phase > This is SBCL 1.0.18, 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. > > This is experimental prerelease support for the Windows platform: use > at your own risk. "Your Kitten of Death awaits!" > Exception Code: 0xc0000005. > Faulting IP: 0x412cb0. > page status: 0x10000. > Was writing: 0, where: 0x3fff8010. > fatal error encountered in SBCL pid 2304(tid 3948): > Exception too early in cold init, cannot continue. > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> unknown command: ``;;;'' > [...] > > > > -- > Brian Mastenbrook > br...@ma... > http://brian.mastenbrook.net/ -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |
From: Nathan F. <fr...@gm...> - 2008-08-15 19:00:14
|
On Fri, Aug 15, 2008 at 2:52 PM, Elliott Slaughter <ell...@gm...> wrote: > Is this normal? It looks a bit strange to me... > > beginning GENESIS, creating core "output/cold-sbcl.core" > /load-cold-foreign-symbol-table FILENAME="src/runtime/sbcl.nm" > [...] > /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4275232 > WARNING: redefining ".text" from #X413C20 to #X409650 > /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4232784 > WARNING: redefining ".text" from #X409650 to #X413C70 > /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4275312 > WARNING: redefining ".text" from #X413C70 to #X406ED0 > /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4222672 > WARNING: redefining ".text" from #X406ED0 to #X413EC0 > [...] > > This repeats several hundred times, for various tags. This looks like something has gone wrong with the filtering of the 'nm' output. There's a step during the build that basically does: nm $NM_OPTIONS $SBCL_BINARY | sed -e $SOME_SED_PROGRAM > sbcl.nm You'll have to figure out if there should be extra bits in NM_OPTIONS or tweaks to SOME_SED_PROGRAM to massage the output to look like what genesis expects to find. -Nathan |
From: Elliott S. <ell...@gm...> - 2008-08-15 21:43:35
|
On Fri, Aug 15, 2008 at 12:00 PM, Nathan Froyd <fr...@gm...> wrote: > On Fri, Aug 15, 2008 at 2:52 PM, Elliott Slaughter > <ell...@gm...> wrote: >> Is this normal? It looks a bit strange to me... >> >> beginning GENESIS, creating core "output/cold-sbcl.core" >> /load-cold-foreign-symbol-table FILENAME="src/runtime/sbcl.nm" >> [...] >> /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4275232 >> WARNING: redefining ".text" from #X413C20 to #X409650 >> /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4232784 >> WARNING: redefining ".text" from #X409650 to #X413C70 >> /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4275312 >> WARNING: redefining ".text" from #X413C70 to #X406ED0 >> /adding to *cold-foreign-symbol-table*: NAME=".text" VALUE=4222672 >> WARNING: redefining ".text" from #X406ED0 to #X413EC0 >> [...] >> >> This repeats several hundred times, for various tags. > > This looks like something has gone wrong with the filtering of the > 'nm' output. There's a step during the build that basically does: > > nm $NM_OPTIONS $SBCL_BINARY | sed -e $SOME_SED_PROGRAM > sbcl.nm > > You'll have to figure out if there should be extra bits in NM_OPTIONS > or tweaks to SOME_SED_PROGRAM to massage the output to look like what > genesis expects to find. Hmm... is it possible this is an existing problem with win32? I seem to run into the same thing when I compile vanilla 1.0.18. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert |