Re: [Sbcl-devel] Problems porting to Solaris on x86-64

[Juho S. <js...@ik...>]

Alex Viskovatoff <vis...@im...> writes:

> Hello all,
> 
> I'm trying to port SBCL 1.0.24 to Solaris on x86-64, but have run into a 
> couple of snags. (I'm sure there will be more.) The last time I believe 
> this was discussed was in this post:
> 
> https://sourceforge.net/mailarchive/forum.php?thread_name=000a01c7ed91%243ab24170%24720210ac%40killer&forum_name=sbcl-devel
> 
> First, the compiler exhibits some bizarre behavior during make-host-2 
> when compiling room.lisp. (The post above mentions the same error with 
> the same file.) If I replace the entire file with the following two lines:
> 
>    (in-package "SB!VM")
>    (defun print-allocated-objects (space))

Unfortunately this is not an interesting example, as that code is
something that one would expect to signal a full warning (unused
variable). In the real code the variable SPACE is certainly used in
that function.

I notice that the actual warning didn't get posted in the thread you
linked to either, so I'll try to be a bit more explicit this time: If
you don't post the actual WARNING or ERROR from compiling the real
file, we can't help you.
 
>  The second snag is that here is what happens when make-target-2 starts 
> (running the 64-bit binary built by make-target-1):
> 
> //entering make-target-2.sh
> //doing warm init - compilation phase
> This is SBCL 1.0.24, 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.
> in core: 0x40000000 - in runtime: 0x20000000
> fatal error encountered in SBCL pid 14457:
> core/runtime address mismatch: READ_ONLY_SPACE_START

That's very strange.

What it's saying is that location where the C code expects the
read-only memory space to be (src/runtime/genesis/constants.h) is
different from what was written to the core file in genesis
(src/compiler/generic/genesis.lisp, in output-gspace). But both of
these should ultimately be derived from src/compiler/x86-64/parms.lisp,
and in fact the header file is also printed by code in genesis.lisp.

One thing you could try is to change the location of the read-only
space a bit, and see whether the "wrong" value also changes. For
example if there's some kind of a bug involving converting a fixnum to
a raw number by shifting away the tag bits, the wrong value would be
off by exactly a factor of two from the right one.

Maybe try replacing:

    (multiple-value-bind (floor rem)
        (floor (gspace-byte-address gspace) sb!c:*backend-page-bytes*)
      (aver (zerop rem))
      (write-word floor))

By:

   (write-word (gspace-byte-address gspace))

Since I think the value in the core file is the wrong one, and that
use of FLOOR is the only difference in the handling of the address
compared to the other values that are written correctly to the core.

> Something that might be relevant is that phase make-host-2 produces lots 
> of messages like

Not relevant, I'm afraid.

-- 
Juho Snellman