-------------------
> In sbcl-0.8.10/x86/Linux, this file
> (cl:in-package :cl-user)
> (defvar *yoworld* "Yo, world.")
> (defun yo () (print *yoworld*))
> (yo)
> compiles to 3325 bytes of .fasl; after mutating the compiler by
> compiling and loading the attached code, it's 2344.
I played with this little patch today, trying to get warm load to use
the patch for compilation (by compiling and loading the file prior to
compiling PCL and suchlike). I found this change was necessary:
(defun quoted-fopcompile (form for-value-p)
(when for-value-p
(let ((sb-fasl::*dump-only-valid-structures* nil))
(dump-object form *compile-object*))))
So that structures will get dumped properly.
All told, the struggle was one of much frustration (and learning about
SBCL), but not much win, except in the size of the .fasl files. Using
the patch saved ~10% on the size of the .fasl files, but the sizes of
the newly dumped cores post-warm load were nearly identical. A
previous attempt to stitch the whole patch into src/compiler/main.lisp
was met with some frustration (bootstrapping issues?); doing things in
warm load seemed easier.
(which is, of course, not to say that it might not be useful
elsewhere...)
-Nathan

--- Vipul Periwal <vipulp@...> wrote:
>
> As you probably know, 64Mb is the default maximum stacksize for the
> Darwin kernel shipped with Panther. So it seems natural that SBCL
> should crap out when I try to make an array (8192 8192) since that is
> going above the 64Mb. It is apparently possible to rebuild the kernel
> to a maximum of 256 Mb, but not higher.
Is the array put into stack, or heap? I would have thought heap.
My linux machine has an 8192K default stack limit, and it can allocate
big arrays just fine (after swapping furiously).
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover

Vipul Periwal <vipulp@...> 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/&gt;.
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.

--- David Steuber <david@...> 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

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.

Julian Squires <tek@...> 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@...:~/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@...:~/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.

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

--- David Steuber <david@...> wrote:
> Brian Downing <bdowning@...> 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

William Harold Newman <william.newman@...> writes:
> Things can be subject to this host-vs.-target distinction even if they
> don't have to do with physical differences between host and target.
> For example, if you change the definition of the PPRINT-LOGICAL-BLOCK
> macro or the layout of the PACKAGE structure, then use SBCL to rebuild
> SBCL, during the compilation the for-the-target macroexpansion of a
> PPRINT-LOGICAL-BLOCK form and the for-the-target address offsets for
> PACKAGE references will not be the same as those used in the host.
This all makes good sense. The only question that leaves me with
then is where is the make-package to go with the in-package? I
missed it with grep.
As to the original subject, I was just thinking (due to a post from
some moments ago) that the threads.impure.lisp test file has some
good examples of using the sb-thread functions. Sometimes it takes
me a while to realize the blindingly obvious. Whether that is
tutorial worthy is another issue. After all, it's ment as a test
harness, not an introduction to sb-thread.
I just need to figure out why the test fails on my SMP box.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.

Brian Downing <bdowning@...> 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.

Raymond Wiker <Raymond.Wiker@...> writes:
> David Steuber writes:
> > Raymond Wiker <Raymond.Wiker@...> 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.

On Thu, Apr 29, 2004 at 01:16:13PM +0300, Nikodemus Siivola wrote:
> On Wed, 28 Apr 2004, David Steuber wrote:
>
> > I've resorted to looking through the source code now. I'm already
> > confused by what I assume are basic things like (in-package
> > "SB!THREAD") instead of (in-package "SB-THREAD") and not being able
> > to find an associated (make-package "SB!THREAD").
>
> The "!" vs. "-" is a bootstrapping mechnism to keep packages being built
> separate from host packages -- towards the end of a build the "SB!FOO" is
> renamed to "SB-FOO".
In case the point in doing this kind of thing is not obvious, consider
running SBCL under Linux to build SBCL for OpenBSD. Various things are
different between the SBCL which is performing the build and the SBCL
which is being built. One example where the differences are
conveniently listed side by side is the memory map, in
src/compiler/x86/parms.lisp. During the build process on Linux we'd have
sb-vm:dynamic-space-start = #x09000000 ; for host Linux
sb!vm:dynamic-space-start = #x80000000 ; for target OpenBSD
Then as Nikodemus notes, later once the host Linux is out of the
picture, so the potential for conflict and confusion is gone, the
packages are renamed so that in the running target OpenBSD we get
sb-vm:dynamic-space-start = #x80000000.
Things can be subject to this host-vs.-target distinction even if they
don't have to do with physical differences between host and target.
For example, if you change the definition of the PPRINT-LOGICAL-BLOCK
macro or the layout of the PACKAGE structure, then use SBCL to rebuild
SBCL, during the compilation the for-the-target macroexpansion of a
PPRINT-LOGICAL-BLOCK form and the for-the-target address offsets for
PACKAGE references will not be the same as those used in the host.
--
William Harold Newman <william.newman@...>
Clan McCthulhu. In the end, there can be only one.
-- Cael at Raytheon Systems Company
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C

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

I've been hacking on MAKE-ARRAY recently, to compile forms with
:INITIAL-CONTENTS more efficiently (currently :INITIAL-CONTENTS always
forces a full call to MAKE-ARRAY).
However, it has dawned to me that most of what I've been doing could be
(maybe) implemented better in terms of a new optimization framework.
The idea would be to extend defknown (or have a mechanism parallel to
defknown) with information about specific arguments:
(defknown make-array ((or index list)
&key
(:element-type type-specifier)
(:initial-element t)
(:initial-contents t)
(:adjustable t)
(:fill-pointer t)
(:displaced-to (or array null))
(:displaced-index-offset index))
array (flushable unsafe))
would be accompanied with:
(defargfold make-array (&rest t))
to indicate that it's safe to constant-fold any argument to make-array (I
hope I'm not mistaken here). Likewise, MAPCAR and MAPLIST would be
accompanied by:
(defargfold mapcar (&rest t))
(defargfold maplist (t &rest nil))
Now, my questions:
0) Does this make sense to anyone else? Is my thinking muddled
and this a bad idea, or just not worth the effort?
1) Does something to do effectively the same already exist in SBCL,
and if so, where can I find it?
2) If this makes sense, and nothing to this effect exists does
anyone have a hunch how hard this would be to do, and where
should I start looking at to do this?
Cheers,
-- Nikodemus

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

David Steuber writes:
> Raymond Wiker <Raymond.Wiker@...> 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.

Raymond Wiker <Raymond.Wiker@...> 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.

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).

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

John Klein <jk271828@...> 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.

--- Julian Squires <tek@...> 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