From: Vipul P. <vi...@ma...> - 2004-04-28 14:26:36
|
Hello, I'm not sure where I should send this, but SBCL bootstrapping had problems with interrupt_handle_now( ... ). I looked at the code in ppc-arch.c and I noticed that there was only one place with this function where an ifdef for DARWIN wasn't in place. Anyhow, if one adds #ifdef LISP_FEATURE_DARWIN sigreturn(contest); #endif just after line 186 in ppc-arch.c, the bootstrapping goes through and one gets a runtime and a core that work. Of course, this doesn't mean that the all the additional tests in the tests (e.g. vector.pure.lisp etc.) directory work but ... V. Periwal, Contractor, Kelly Scientific Resources |
From: Julian S. <te...@wi...> - 2004-04-28 16:33:12
|
On Wed, Apr 28, 2004 at 10:26:22AM -0400, Vipul Periwal wrote: > I'm not sure where I should send this, but SBCL bootstrapping had > problems with interrupt_handle_now( ... ). I looked at the code in > ppc-arch.c and I noticed that there was only one place with this > function where an ifdef for DARWIN wasn't in place. Anyhow, if one > adds > > #ifdef LISP_FEATURE_DARWIN > sigreturn(contest); > #endif > > just after line 186 in ppc-arch.c, the bootstrapping goes through and > one gets a runtime and a core that work. Of course, this doesn't mean > that the all the additional tests in the tests (e.g. vector.pure.lisp > etc.) directory work but ... Cool, but... are you sure this does anything? AFAICS, sigreturn gets called anyway (outside the switch()), and the build still doesn't work (at least for me). Did you do your build with any additional features, such as LDB? Cheers. -- Julian Squires |
From: John K. <jk2...@ya...> - 2004-04-28 19:10:12
|
--- Vipul Periwal <vi...@ma...> wrote: > #ifdef LISP_FEATURE_DARWIN > sigreturn(contest); > #endif > just after line 186 in ppc-arch.c, ..... Another datum: this change makes 0.8.10 build successfully, whereas it didn't build the first time. Which seems weird, given the point that sigreturn should get called anyway. Alas, this version still dies when allocating big arrays.. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: David S. <da...@da...> - 2004-04-28 20:44:29
|
John Klein <jk2...@ya...> writes: > Alas, this version still dies when allocating big arrays.. I've been working on other things, so I still have no clue as to how to track down this mystery. I have had the thought that this might be why OpenMCL has a smaller ARRAY-TOTAL-SIZE-LIMIT than SBCL. Although making it that size for SBCL would not constitute a fix in my opinion. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: Julian S. <te...@wi...> - 2004-04-28 20:59:21
|
On Wed, Apr 28, 2004 at 12:09:18PM -0700, John Klein wrote: > > --- Vipul Periwal <vi...@ma...> wrote: > > #ifdef LISP_FEATURE_DARWIN > > sigreturn(contest); > > #endif > > just after line 186 in ppc-arch.c, ..... > > Another datum: this change makes 0.8.10 build successfully, > whereas it didn't build the first time. Which seems weird, > given the point that sigreturn should get called anyway. Hmm. I've tried building twice with this change, a second time to make sure I didn't mess something up, and it still failed. I'm using gcc 3.3 on a 10.2.8 box. So far, the only way to get a correct build for me is by including SB-LDB. Maybe it's some kind of alignment issue, and that's why this works for you and Vipul but not me? I suppose one could try replacing it with something similarly useless? Cheers. -- Julian Squires |
From: John K. <jk2...@ya...> - 2004-04-29 02:20:32
|
--- Julian Squires <te...@wi...> wrote: > Hmm. I've tried building twice with this change, a second time to make > sure I didn't mess something up, and it still failed. I'm using gcc 3.3 > on a 10.2.8 box. So far, the only way to get a correct build for me is > by including SB-LDB. Maybe it's some kind of alignment issue, and > that's why this works for you and Vipul but not me? I suppose one could > try replacing it with something similarly useless? OK. I've tried the following (with sh clean.sh between every compilation) 1) compile as-is 0.8.10 on OS X 10.3 gcc 3.3 => BUILD-FAILS (cold-sbcl.core, but no sbcl.core) 2) compile inserting #ifdef LISP_FEATURE_DARWIN sigreturn(context); #endif in ppc-arch.c at end of :default case in sigtrap_handler() => BUILD SUCCEEDS 3) put a function int donothing(int j) { if (j==666) lose("this should not happen"); return 0; } just before sigtrap_handler in ppc-arch.c, and replace the call to sigreturn with donothing(99) => BUILD SUCCEEDS 4) comment out call to donothing, but leave the function defintion of donothing in. => BUILD SUCCEEDS (!) 5) comment out the function definition of donothing to bring us back to original state, plus some commented out code. => BUILD FAILS So it looks like you might be right and it could be an alignment issue. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: David S. <da...@da...> - 2004-04-29 06:07:02
|
John Klein <jk2...@ya...> writes: [interesting experiment] > So it looks like you might be right and it could be an alignment issue. Did you by any chance note the size of the sbcl executable for the builds? I would expect GCC to produce good code for that unless the compiler and linker settings were completely wrong. How does the size of the mach-o executable affect the way the core file comes out either in terms of size or how it is loaded into memory? I'm not sure where to look in my documentation, but I presume there is a specification somewhere for mach-o executables and dylib files. More importantly, there should be documentation for the instruction alignment for PPC executables. Is it 32 bit word aligned or 64 bit word aligned? Aren't all instructions the same size? I came to believe that the way SBCL worked was by memory mapping the core file into virtual memory at a fixed location. So that should mean that the core file is appropriately structured for the PPC architecture when things go well. What I don't understand is how the core file comes out differently (if indeed it does) just because some C code is a little different. I'm not saying you're wrong. I can't make that determination. I do find it odd enough to make me go, "huh?" One thing that has always puzzled me about building SBCL is the way the final sbcl.core size will just change from build to build of the same code base. I first built SBCL successfully using OpenMCL. From that point on, I did my builds with SBCL itself. Even without doing an update (although not running clean.sh), the sbcl.core file would come out to a different size each time. I don't know why this should be so, but it is definitely not what I would expect from a deterministic process. Mind you, I am also puzzled as to why including the sb-ldb feature would make a build succeed. I only enabled it to trap the bug related to creating a large array of double-floats. I'm going to go ahead an try a few build experiments with the code I have on hand (no cvs update) to see if I can get the build failure and reproduce your results. I don't expect to solve anything, but maybe I can add another data point. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: Nikodemus S. <tsi...@cc...> - 2004-04-29 10:22:39
|
On Thu, 29 Apr 2004, David Steuber wrote: > How does the size of the mach-o executable affect the way the core > file comes out either in terms of size or how it is loaded into > memory? Provided you're referring to sbcl.core, not at all unless things are horribly broken. The core file is produced by lisp code, and contains lisp code only -- the only ways the runtime affects it is garbage collections and mmap on startup. > Mind you, I am also puzzled as to why including the sb-ldb feature > would make a build succeed. I only enabled it to trap the bug > related to creating a large array of double-floats. SB-LDB is pretty much all C code, so to my mind it's magical effect suggests GCC trouble. Cheers, -- Nikodemus |
From: Raymond W. <Ray...@fa...> - 2004-04-29 10:38:06
|
Nikodemus Siivola writes: > On Thu, 29 Apr 2004, David Steuber wrote: > > > How does the size of the mach-o executable affect the way the core > > file comes out either in terms of size or how it is loaded into > > memory? > > Provided you're referring to sbcl.core, not at all unless things are > horribly broken. The core file is produced by lisp code, and contains lisp > code only -- the only ways the runtime affects it is garbage collections > and mmap on startup. > > > Mind you, I am also puzzled as to why including the sb-ldb feature > > would make a build succeed. I only enabled it to trap the bug > > related to creating a large array of double-floats. > > SB-LDB is pretty much all C code, so to my mind it's magical effect > suggests GCC trouble. Since this is MacOSX... ... what does gcc_select say? My PowerBook is set up to use gcc 3.1, and I have built SBCL relatively recently (0.8.9.48). |
From: David S. <da...@da...> - 2004-04-29 11:44:56
|
Raymond Wiker <Ray...@fa...> writes: > Nikodemus Siivola writes: > > > > SB-LDB is pretty much all C code, so to my mind it's magical effect > > suggests GCC trouble. > > Since this is MacOSX... > > ... what does gcc_select say? My PowerBook is set up to use gcc 3.1, > and I have built SBCL relatively recently (0.8.9.48). On my system: $ gcc_select Current default compiler: gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) Also, with or without :sb_ldb I get the same cold-sbcl.core size: $ ls -l output/cold-sbcl.core ~/tmp/sbcl/output/cold-sbcl.core -rw-r--r-- 1 david staff 23228416 29 Apr 03:01 /Users/david/tmp/sbcl/output/cold-sbcl.core -rw-r--r-- 1 david staff 23228416 29 Apr 06:15 output/cold-sbcl.core Unfortunately, they diff different. I guess timestamp info or something is getting in there. According to grep, there are only three files with LISP_FEATURE_SB_LDB: $ find src -name '*.c' -exec grep -l LISP_FEATURE_SB_LDB {} \; src/runtime/monitor.c src/runtime/parse.c src/runtime/print.c monitor.c contains the function that prints out the hard luck message when the build without :sb-ldb tries to do the warm init before purification. The other two do nothing without the define. I don't really think this is a bug in GCC, but I guess anything is possible until this is cracked. Right now, I am thinking that the purify process might be borked somehow. But that is just a wild guess as it is around that time that the signal 4 (SIGILL) doesn't get handled with the build that fails. I don't know if the purify is pure Lisp or involves C. I wouldn't expect any changes to that recently, so I am probably wrong in guessing that is the problem. Really what needs to be done is to run the src/runtime/sbcl file in gdb (with debug info having been included and no optimization) as it is run by make-target-2.sh: ./src/runtime/sbcl \ --core output/cold-sbcl.core \ --sysinit /dev/null --userinit /dev/null <<-'EOF' || exit 1 ;; Now that we use the compiler for macros, interpreted ;; /SHOW doesn't work until later in init. #+sb-show (print "/hello, world!") (sb!ext:purify) That should be far enough to trigger the SIGILL. If I knew gdb, I would be on it right now. I wonder if this can be setup in Xcode? That has a nice front end to gdb. Actually, I think I would have a userinit file that contains the sb-show and purify forms so that gdb could just be fired up with src/runtime/sbcl as its arg with the command line args in place. What is the normal procedure for this? Or does each developer have his own preference? Hmmm. Marvel Comics just called me to say that Captain Obvious is their trademarked super hero. Oh well. I better not post this. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: Julian S. <te...@wi...> - 2004-04-29 10:49:47
|
On Wed, Apr 28, 2004 at 07:20:32PM -0700, John Klein wrote: > OK. I've tried the following (with sh clean.sh between every compilation) <snip.> > 4) comment out call to donothing, but leave the function defintion of > donothing in. > => BUILD SUCCEEDS (!) Yikes! Thanks for trying this out. I'll keep poking at this. Cheers. -- Julian Squires |
From: Raymond W. <Ray...@fa...> - 2004-04-29 11:57:46
|
David Steuber writes: > Raymond Wiker <Ray...@fa...> writes: > > > Nikodemus Siivola writes: > > > > > > SB-LDB is pretty much all C code, so to my mind it's magical effect > > > suggests GCC trouble. > > > > Since this is MacOSX... > > > > ... what does gcc_select say? My PowerBook is set up to use gcc 3.1, > > and I have built SBCL relatively recently (0.8.9.48). > > On my system: > > $ gcc_select > Current default compiler: > gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) Back in July 2003, Brian Mastenbrook stated that : SBCL on OS X can't compile under Apple's new gcc 3.3 prerelease for : some reason, so be sure to run "sudo gcc_select 3.1" before : compiling SBCL. That's probably the reason that my powerbook is (still) set up to use gcc 3.1. I'm not sure if this is also the reason that I have been able to compile SBCL 0.9.8.48, or if the problems you are experiencing have been introduced later. |
From: Julian S. <te...@wi...> - 2004-04-29 12:09:14
|
On Thu, Apr 29, 2004 at 01:57:29PM +0200, Raymond Wiker wrote: > Back in July 2003, Brian Mastenbrook stated that > > : SBCL on OS X can't compile under Apple's new gcc 3.3 prerelease for > : some reason, so be sure to run "sudo gcc_select 3.1" before > : compiling SBCL. > > That's probably the reason that my powerbook is (still) set up > to use gcc 3.1. I'm not sure if this is also the reason that I have > been able to compile SBCL 0.9.8.48, or if the problems you are > experiencing have been introduced later. Another data point: it does not compile successfully for me with gcc 3.3 or gcc 3.1. I believe someone else on IRC had the same results. Cheers. -- Julian Squires |
From: David S. <da...@da...> - 2004-04-29 15:17:50
|
Raymond Wiker <Ray...@fa...> writes: > David Steuber writes: > > Raymond Wiker <Ray...@fa...> writes: > > > > > Nikodemus Siivola writes: > > > > > > > > SB-LDB is pretty much all C code, so to my mind it's magical effect > > > > suggests GCC trouble. > > > > > > Since this is MacOSX... > > > > > > ... what does gcc_select say? My PowerBook is set up to use gcc 3.1, > > > and I have built SBCL relatively recently (0.8.9.48). > > > > On my system: > > > > $ gcc_select > > Current default compiler: > > gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) > > Back in July 2003, Brian Mastenbrook stated that > > : SBCL on OS X can't compile under Apple's new gcc 3.3 prerelease for > : some reason, so be sure to run "sudo gcc_select 3.1" before > : compiling SBCL. > > That's probably the reason that my powerbook is (still) set up > to use gcc 3.1. I'm not sure if this is also the reason that I have > been able to compile SBCL 0.9.8.48, or if the problems you are > experiencing have been introduced later. Maybe 3.3 was a problem in the past. I've been compiling SBCL with it all this time. This is a recent break. I've tried 3.1 and got precisely the same results. I did not try going back to 2.95. When I get a chance, I'm going to figure out how to get debug info into ./src/runtime/sbcl (assuming it's not in there already) and get the warm init to run in gdb. With luck, someone will beat me to this. I have no experience in this area. I already know from looking at the code that the lose function is being called because of the SIGILL and that the handler in place sends to monitor.c where the out of luck message is generated if sb-ldb hasn't been turned on in the features. I just wish ppc-arch.c didn't have so many magic numbers in it. I know C doesn't have the C++ const specifier, but #defines can be used for bitmasks. Sure, I can tell what numbers are being masked against with a little effort to convert from decimal to hex. But without mnemonic names, I won't know why or what for. Then again, I don't even know what SIGILL means. I'm sure it's a POSIX name for something that I can find somewhere. What really doesn't make sense to me is why the sb-ldb feature makes such a difference. The same cold-sbcl.core file seems to be loaded. Then either the "hello, world" or purify nails it. Or perhaps it gets nailed even before then. Only a debugger will tell. It all starts with a stack trace. Well, assuming those lngjmps and signal handlers don't make that impossible. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: Brian D. <bdo...@la...> - 2004-04-29 12:43:10
|
On Thu, Apr 29, 2004 at 12:37:49PM +0200, Raymond Wiker wrote: > > SB-LDB is pretty much all C code, so to my mind it's magical effect > > suggests GCC trouble. > > Since this is MacOSX... > > ... what does gcc_select say? My PowerBook is set up to use gcc 3.1, > and I have built SBCL relatively recently (0.8.9.48). Note that currently the SBCL build hardcodes gcc 3.1, since several SBCL releases ago gcc 3.3 was producing SBCLs that were unstable: ------------------------------------------------------------------------ :; cat src/runtime/Config.ppc-darwin # -*- makefile -*- CFLAGS = -Dppc -g -Wall -O3 -no-cpp-precomp OS_SRC = bsd-os.c os-common.c ppc-darwin-os.c ppc-darwin-dlshim.c OS_LIBS = -lSystem -lc -lm # Avoid the gcc 3.3 prerelease tarpit of death! CC = gcc3 ..... ------------------------------------------------------------------------ If you want to try gcc-3.3 replace this with CC = gcc-3.3 If this time changing the compiler to gcc 3.3 makes a working SBCL, then there is probably some problem going on that is not directly a GCC problem, but which the different runtime builds from 3.1 or 3.3 trigger, just as a 3.1-built runtime with SB-LDB works while a 3.1-built runtime without SB-LDB fails. -bcd |
From: David S. <da...@da...> - 2004-04-29 15:23:35
|
Brian Downing <bdo...@la...> writes: > Note that currently the SBCL build hardcodes gcc 3.1, since several SBCL > releases ago gcc 3.3 was producing SBCLs that were unstable: > > ------------------------------------------------------------------------ > :; cat src/runtime/Config.ppc-darwin > # -*- makefile -*- > CFLAGS = -Dppc -g -Wall -O3 -no-cpp-precomp > OS_SRC = bsd-os.c os-common.c ppc-darwin-os.c ppc-darwin-dlshim.c > OS_LIBS = -lSystem -lc -lm > > # Avoid the gcc 3.3 prerelease tarpit of death! > CC = gcc3 > ..... > ------------------------------------------------------------------------ > > If you want to try gcc-3.3 replace this with > > CC = gcc-3.3 > > If this time changing the compiler to gcc 3.3 makes a working SBCL, then > there is probably some problem going on that is not directly a GCC > problem, but which the different runtime builds from 3.1 or 3.3 trigger, > just as a 3.1-built runtime with SB-LDB works while a 3.1-built runtime > without SB-LDB fails. Ah. I didn't think to look there. Ok. Something else to check then. gcc_select I think changes more than just the compiler version. I think it also changes linker settings and target libraries. Although I wasn't paying super close attention to the error messages that were flying by when I forgot to use sudo to gcc_select 3.1 -root. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: John K. <jk2...@ya...> - 2004-04-29 21:38:18
|
--- David Steuber <da...@da...> wrote: > Brian Downing <bdo...@la...> writes: > > Note that currently the SBCL build hardcodes gcc 3.1, since several SBCL > > releases ago gcc 3.3 was producing SBCLs that were unstable:...... > > :; cat src/runtime/Config.ppc-darwin > > # -*- makefile -*- > > ...... > > # Avoid the gcc 3.3 prerelease tarpit of death! > > CC = gcc3 > > Ah. I didn't think to look there. Ok. Something else to check then. > > gcc_select I think changes more than just the compiler version. I > think it also changes linker settings and target libraries. Earlier I noted that putting an unused dummy function in ppc-arch.c allows 0.8.10 to build on OSX 10.3, but I was implicitly using the default gcc_select 3.3 After doing 'sudo gcc_select 3.1', building without putting int donothing(int j) { if (j==666) lose("this should not happen"); return 0; } just before static void sigtrap_handler(...) in ppc-arch.c the build still fails, as it did with the implicit gcc_select 3.3 However putting this uncalled function into ppc-arch.c and building after gcc_select 3.1 DOES succeed, as with the original gcc_select 3.3 example. So gcc_select 3.1 vs 3.3 makes no difference, if this isn't obvious already, as long as the build script has 3.1 (that is, CC=gcc3) (The gcc_select 3.1 version, like the 3.3 version, dies when allocating big arrays, but that is another matter). Next, I tried putting gcc-3.3 into src/runtime/Config.ppc-darwin and putting gcc_selecect back to 3.3. The build (without the extra dummy function) froze for about 10 minutes with the last message as follows - I killed the build at this point. ; compiling DEFUN CAN-OPTIMIZE-ACCESS: ; compiling top level form: ; recognizing DEFUN CAN-OPTIMIZE-ACCESS1 ; compiling top level form: [FROZEN, with only a cold-sbcl.core present] If I put donothing back in, then it still freezes at this point. Summary: Using CC=gcc3 in the build script causes the build to succeed whether or not gcc_select 3.1 is used, but only if the dummy function (or LDB presumably) is included. Using CC=gcc-3.3 in the build script causes the build to fail, freezing at the above point, whether or not the extra dummy function is included. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: Julian S. <te...@wi...> - 2004-04-29 21:43:12
|
On Thu, Apr 29, 2004 at 02:38:17PM -0700, John Klein wrote: > Summary: Using CC=gcc3 in the build script causes the build to succeed > whether or not gcc_select 3.1 is used, but only if > the dummy function (or LDB presumably) is included. Using CC=gcc-3.3 > in the build script causes the build to fail, freezing at the above > point, whether or not the extra dummy function is included. Except on my 10.2.8 G5, where using CC=gcc and gcc_select 3.3 appears to build fine, sans dummy fixup. Can anyone else reproduce this? Cheers. -- Julian Squires |
From: David S. <da...@da...> - 2004-04-29 23:16:58
|
Julian Squires <te...@wi...> writes: > On Thu, Apr 29, 2004 at 02:38:17PM -0700, John Klein wrote: > > Summary: Using CC=gcc3 in the build script causes the build to succeed > > whether or not gcc_select 3.1 is used, but only if > > the dummy function (or LDB presumably) is included. Using CC=gcc-3.3 > > in the build script causes the build to fail, freezing at the above > > point, whether or not the extra dummy function is included. > > Except on my 10.2.8 G5, where using CC=gcc and gcc_select 3.3 appears to > build fine, sans dummy fixup. Can anyone else reproduce this? I need a dual 2Ghz G5. My machine is just too damn slow. I've got another data point that should prove to be fun. I left out sb-ldb and still managed to get a clean build even though I expected it to fail. First, the global machine setting for gcc: david@interloper:~/usr/src/sbcl/sbcl $ gcc_select Current default compiler: gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) Now a diff of the only file I changed. I made more than one change, so some twiddling is necessary to find out what triggers the build failure: david@interloper:~/usr/src/sbcl/sbcl $ cvs diff -u src/runtime/Config.ppc-darwin Index: src/runtime/Config.ppc-darwin =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/Config.ppc-darwin,v retrieving revision 1.4 diff -u -r1.4 Config.ppc-darwin --- src/runtime/Config.ppc-darwin 25 Feb 2004 17:41:44 -0000 1.4 +++ src/runtime/Config.ppc-darwin 29 Apr 2004 22:45:28 -0000 @@ -1,10 +1,13 @@ # -*- makefile -*- -CFLAGS = -Dppc -g -Wall -O3 -no-cpp-precomp +# CFLAGS = -Dppc -g -Wall -O3 -no-cpp-precomp +# No optimization, no warnings, but lottsa debug info for gdb +CFLAGS = -Dppc -g3 -ggdp -w -no-cpp-precomp OS_SRC = bsd-os.c os-common.c ppc-darwin-os.c ppc-darwin-dlshim.c OS_LIBS = -lSystem -lc -lm # Avoid the gcc 3.3 prerelease tarpit of death! -CC = gcc3 +# CC = gcc3 +CC = gcc-3.3 ASSEM_SRC = ppc-assem.S ldso-stubs.S ARCH_SRC = ppc-arch.c @@ -20,7 +23,7 @@ # FIXME: "-Wl,-segaddr,SBCLRO,0x1000000" is output from # ppc-darwin-mkrospace (it depends on READ_ONLY_SPACE I believe) but it # is hard-coded here! -OS_LINK_FLAGS = -dynamic -L$(HOME)/local/lib -L/sw/lib -L/opt/local/lib -L/usr/local/lib -Wl,-segaddr,SBCLRO,0x1000000 -Wl,-seg1addr,0x5000000 $(if $(AFTER_GROVEL_HEADERS),ppc-darwin-rospace.o) +OS_LINK_FLAGS = -dynamic -L$(HOME)/usr/lib -L/usr/local/lib -Wl,-segaddr,SBCLRO,0x1000000 -Wl,-seg1addr,0x5000000 $(if $(AFTER_GROVEL_HEADERS),ppc-darwin-rospace.o) GC_SRC= cheneygc.c I set CC to gcc-3.3 to match the system. BUT I also changed the CFLAGS to add extra debug info for gdb and turn off optimizations. Turning off warnings shouldn't have made a difference. Neither should the path change for OS_LINK_FLAGS. I would actually recomend the removal of /sw/lib and /opt/local/lib. The target machine may not have Fink or Darwin Ports installed. Besides, I think SBCL should build with the standard Apple shipped configuration + Xcode 1.1 or later (which has the GCC stuff). The size of cold-sbcl.core is not affected by these changes. It is all in the sbcl runtime. What we have here is a Heisenbug. Well, I can't be certain. P.S. Reading back over this post, I see I typod the -ggdb option. Oops. I wonder how that worked. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: David S. <da...@da...> - 2004-04-30 03:53:17
|
I'm able to build SBCL 0.8.10 without the sb-ldb feature on my G4 running OS X 10.3.3. I'm talking a clean build after running ./clean.sh. No changes to source are required with the exception of src/runtime/Config.ppc-darwin. I think all that is really required is to go from O3 to O2. I've also gone from gcc3 to gcc-3.3. It works. I think the build failure is some sort of optimization bug in the GCC compiler, but I haven't cracked that yet. I doubt any performance difference will be noticed between O3 and O2 but I suppose one might find a bench that will measure a difference. Here are my changes for anyone who is interested: $ cvs diff src/runtime/Config.ppc-darwin Index: src/runtime/Config.ppc-darwin =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/runtime/Config.ppc-darwin,v retrieving revision 1.4 diff -r1.4 Config.ppc-darwin 2c2,5 < CFLAGS = -Dppc -g -Wall -O3 -no-cpp-precomp --- > # CFLAGS = -Dppc -g -Wall -O3 -no-cpp-precomp > # No optimization, no warnings, but lottsa debug info for gdb > # CFLAGS = -Dppc -g3 -ggdb -w -no-cpp-precomp > CFLAGS = -Dppc -g -w -O2 -no-cpp-precomp 7c10,11 < CC = gcc3 --- > # CC = gcc3 > CC = gcc-3.3 23c27 < OS_LINK_FLAGS = -dynamic -L$(HOME)/local/lib -L/sw/lib -L/opt/local/lib -L/usr/local/lib -Wl,-segaddr,SBCLRO,0x1000000 -Wl,-seg1addr,0x5000000 $(if $(AFTER_GROVEL_HEADERS),ppc-darwin-rospace.o) --- > OS_LINK_FLAGS = -dynamic -L$(HOME)/usr/lib -L/usr/local/lib -Wl,-segaddr,SBCLRO,0x1000000 -Wl,-seg1addr,0x5000000 $(if $(AFTER_GROVEL_HEADERS),ppc-darwin-rospace.o) I've also trimmed the OS_LINK_FLAGS a bit. If you want, you can keep -Wall. I don't think it affects code generation. I turned off the warnings because they were just noise. Well, pointer to integer conversions are not really kosher. They're fine though so long as the int and the pointer are the same size. There is still an outstanding bug in 0.8.10 for making a large array. This form will fail: (let ((f (make-array '(4096 4096) :element-type 'double-float))) (= (aref f 10 11) 99d0)) set_auto_gc_trigger: tried to set gc trigger too high! (0x81ae68c) fatal error encountered in SBCL pid 18461: The problem seems to be caught in src/runtime/cheneygc.c. If sb-ldb is enabled, you get dropped into LDB. If you add an :initial-element 0D0, then you get to wait a long time. I've yet to have the patience to see how that turns out. (let ((f (make-array '(4096 4096)))) (setf (aref f 0 0) 1)) works fine. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: John K. <jk2...@ya...> - 2004-04-30 04:57:20
|
--- David Steuber <da...@da...> wrote: > I'm able to build SBCL 0.8.10 without the sb-ldb feature on my G4 > running OS X 10.3.3. I'm talking a clean build after running > ./clean.sh. No changes to source are required with the exception of > src/runtime/Config.ppc-darwin. I think all that is really required > is to go from O3 to O2. Great. I can confirm that this works on a G5 as well. > [dbl float array generation fails but] > (let ((f (make-array '(4096 4096)))) (setf (aref f 0 0) 1)) [succeeds ] > But not (let ((f (make-array '(4096 8192)))) (setf (aref f 0 0) 1)) even though (< (* 4096 8192) array-total-size-limit) => T It appears to be triggered the total amount of memory used, and double-floats use twice as much as general pointer arrays. I tried turning off all optimizations in gcc just in case it is another gcc bug, but it didn't help. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: Vipul P. <vi...@ma...> - 2004-04-30 13:21:33
|
G5 works, but the bsd-sockets contrib module does not get built. All the other contrib modules did get built. The vector.pure.lisp test crashes. However, I set ulimit -s 65536 and I had no problem with (let ((f (make-array '(4096 8192)))) (setf (aref f 0 0) 1)) but (let ((f (make-array '(8192 8192)))) (setf (aref f 0 0) 1)) caused a crash. The message was set_auto_gc_trigger: tried to set gc trigger too high! (0x180b0ef4) V. Periwal, Contractor, Kelly Scientific Resources |
From: David S. <da...@da...> - 2004-04-30 17:25:20
|
Vipul Periwal <vi...@ma...> writes: > G5 works, but the bsd-sockets contrib module does not get built. All > the other contrib modules did get built. The vector.pure.lisp test > crashes. I've not gone through the tests. It would certainly be nice to have them all work on the ppc-darwin arch. I had all 13 contribs build. This is not to say that they all work, but: $ sbcl This is SBCL 0.8.10, 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. * (require :sb-simple-streams) ; loading system definition from ; #P"/Users/david/usr/lib/sbcl/systems/sb-posix.asd" into #<PACKAGE "ASDF2760"> ; registering #<SYSTEM SB-POSIX {40C46069}> as SB-POSIX ; registering #<SYSTEM SB-POSIX-TESTS {481B9F61}> as SB-POSIX-TESTS ; loading system definition from ; #P"/Users/david/usr/lib/sbcl/systems/sb-bsd-sockets.asd" into ; #<PACKAGE "ASDF2900"> ; registering #<SYSTEM SB-BSD-SOCKETS {4059AF31}> as SB-BSD-SOCKETS ; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {408A3221}> as SB-BSD-SOCKETS-TESTS ("SB-SIMPLE-STREAMS" "SB-POSIX" "SB-BSD-SOCKETS" "SB-GROVEL" "ASDF") * (quit) I tar'd up my installed binaries (I cleaned out the old, so there should be no cruft) and put the tar on my webserver if you want to try it: http://www.david-steuber.com/~david/Lisp/SBCL/sbcl-0.8.10-no-ldb-g4-darwin-10.3.3.tar.gz MD5 (sbcl-0.8.10-no-ldb-g4-darwin-10.3.3.tar.gz) = b33e544fd2d9338e4a5cba981e4f6755 I don't have anything in the extra link dirs mentioned in Config.ppc-darwin. I don't know what impact that may have. > However, I set ulimit -s 65536 and I had no problem with > > (let ((f (make-array '(4096 8192)))) (setf (aref f 0 0) 1)) > > but > (let ((f (make-array '(8192 8192)))) (setf (aref f 0 0) 1)) > > caused a crash. The message was > set_auto_gc_trigger: tried to set gc trigger too high! (0x180b0ef4) This sends my CPU to 100% with most of the time in system (activity monitor is nice): (let ((a (make-array (1- array-total-size-limit)))) (setf (aref a 0) 1)) I have to knock one off the array-total-size-limit or I get thrown into the debugger for this: * (let ((a (make-array array-total-size-limit))) (setf (aref a 0) 1)) ; in: LAMBDA NIL ; (MAKE-ARRAY ARRAY-TOTAL-SIZE-LIMIT) ; ; note: deleting unreachable code ; ; caught WARNING: ; Asserted type (OR (MOD 536870911) CONS NULL) conflicts with derived type ; (VALUES (INTEGER 536870911 536870911) &OPTIONAL). ; compilation unit finished ; caught 1 WARNING condition ; printed 1 note debugger invoked on a TYPE-ERROR in thread 19741: The value 536870911 is not of type (OR (MOD 536870911) CONS NULL). I don't know how long standing it is, whether it was introduced by Panther, or what. But I'm guessing that this is a GC issue. I don't know how the memory management works, but that's what I would start looking at. OpenMCL (with its smaller array-total-size-limit works: $ openmcl Welcome to OpenMCL Version (Beta: Darwin) 0.14.1-p1! ? (let ((a (make-array array-total-size-limit))) (setf (aref a 0) 1)) > Error in process listener(1): value 16777216 is not of the expected type (UNSIGNED-BYTE 24). > While executing: #<Anonymous Function #x539D8EE> > Type :POP to abort. Type :? for other options. 1 > :pop ? (let ((a (make-array (1- array-total-size-limit)))) (setf (aref a 0) 1)) 1 ? I find it interesting that neither likes to use the actual array-total-size-limit. Maybe the mystery is resolved in the CLHS. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: John K. <jk2...@ya...> - 2004-05-01 00:58:40
|
--- David Steuber <da...@da...> wrote: > Vipul Periwal <vi...@ma...> writes: > > > G5 works, but the bsd-sockets contrib module does not get built. All > > the other contrib modules did get built. The vector.pure.lisp test > > crashes. > > I've not gone through the tests. It would certainly be nice to have > them all work on the ppc-darwin arch. I had all 13 contribs build. > This is not to say that they all work, but: > > $ sbcl > This is SBCL 0.8.10, 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. > * (require :sb-simple-streams) > > ; loading system definition from > ; #P"/Users/david/usr/lib/sbcl/systems/sb-posix.asd" into #<PACKAGE > "ASDF2760"> > ; registering #<SYSTEM SB-POSIX {40C46069}> as SB-POSIX > ; registering #<SYSTEM SB-POSIX-TESTS {481B9F61}> as SB-POSIX-TESTS > ; loading system definition from > ; #P"/Users/david/usr/lib/sbcl/systems/sb-bsd-sockets.asd" into > ; #<PACKAGE "ASDF2900"> > ; registering #<SYSTEM SB-BSD-SOCKETS {4059AF31}> as SB-BSD-SOCKETS > ; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {408A3221}> as > SB-BSD-SOCKETS-TESTS > ("SB-SIMPLE-STREAMS" "SB-POSIX" "SB-BSD-SOCKETS" "SB-GROVEL" "ASDF") > * (quit) > > I tar'd up my installed binaries (I cleaned out the old, so there > should be no cruft) and put the tar on my webserver if you want to > try it: > > http://www.david-steuber.com/~david/Lisp/SBCL/sbcl-0.8.10-no-ldb-g4-darwin-10.3.3.tar.gz > MD5 (sbcl-0.8.10-no-ldb-g4-darwin-10.3.3.tar.gz) = > b33e544fd2d9338e4a5cba981e4f6755 > > I don't have anything in the extra link dirs mentioned in > Config.ppc-darwin. I don't know what impact that may have. > > > However, I set ulimit -s 65536 and I had no problem with > > > > (let ((f (make-array '(4096 8192)))) (setf (aref f 0 0) 1)) > > > > but > > (let ((f (make-array '(8192 8192)))) (setf (aref f 0 0) 1)) > > > > caused a crash. The message was > > set_auto_gc_trigger: tried to set gc trigger too high! (0x180b0ef4) > > This sends my CPU to 100% with most of the time in system (activity > monitor is nice): > > (let ((a (make-array (1- array-total-size-limit)))) (setf (aref a 0) 1)) > > I have to knock one off the array-total-size-limit or I get thrown > into the debugger for this: > > * (let ((a (make-array array-total-size-limit))) (setf (aref a 0) 1)) > ; in: LAMBDA NIL > ; (MAKE-ARRAY ARRAY-TOTAL-SIZE-LIMIT) > ; > ; note: deleting unreachable code > ; > ; caught WARNING: > ; Asserted type (OR (MOD 536870911) CONS NULL) conflicts with derived type > ; (VALUES (INTEGER 536870911 536870911) &OPTIONAL). > ; compilation unit finished > ; caught 1 WARNING condition > ; printed 1 note > > debugger invoked on a TYPE-ERROR in thread 19741: > The value 536870911 is not of type (OR (MOD 536870911) CONS NULL). > > I don't know how long standing it is, whether it was introduced by > Panther, or what. But I'm guessing that this is a GC issue. I don't > know how the memory management works, but that's what I would start > looking at. > > OpenMCL (with its smaller array-total-size-limit works: > > $ openmcl > Welcome to OpenMCL Version (Beta: Darwin) 0.14.1-p1! > ? (let ((a (make-array array-total-size-limit))) (setf (aref a 0) 1)) > > Error in process listener(1): value 16777216 is not of the expected type > (UNSIGNED-BYTE 24). > > While executing: #<Anonymous Function #x539D8EE> > > Type :POP to abort. > Type :? for other options. > 1 > :pop > > ? (let ((a (make-array (1- array-total-size-limit)))) (setf (aref a 0) 1)) > 1 > ? > > I find it interesting that neither likes to use the actual > array-total-size-limit. Maybe the mystery is resolved in the CLHS. > > -- > I wouldn't mind the rat race so much if it wasn't for all the damn cats. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: John K. <jk2...@ya...> - 2004-05-01 01:07:22
|
First, apologies for the blank mail. > > I find it interesting that neither likes to use the actual > array-total-size-limit. Maybe the mystery is resolved in the CLHS. > Yes, the clhs says that array-total-size-limit is: "The upper _exclusive_ bound on the array total size of an array." So there is nothing wrong with the behaviour as described. incidentally SBCL/CMUCL make array-total-size-limit as big as possible given the requirement that it be a fixum ie, (= array-total-size-limit most-positive-fixnum) => T openmcl elects to make array-total-size-limit much smaller than most-positive-fixnum for some reason. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |