Re: Trouble building 2.49.60 beta on Fedora

Bruno Haible <[email protected]>
Newsgroups gmane.lisp.clisp.devel
Message-ID <3991229.HNhAyd533b@omega>
Jerry James wrote:
> the s390x, ppc64 and ppc64le builds all fail with this message:
> 
> ../src/lispbibl.d:2987:2: error: #error CLISP has not been ported to
> this platform - oint_type_len undefined
>  #error CLISP has not been ported to this platform - oint_type_len undefined

For s390x support, please try this patch.

Bruno

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel
s390x.diff (text/x-patch, 5 KB)
diff -r 92d52f80a4e4 -r 5a3a37e01f03 src/lispbibl.d
--- a/src/lispbibl.d	Mon Aug 21 00:00:39 2017 +0200
+++ b/src/lispbibl.d	Mon Aug 21 01:59:25 2017 +0200
@@ -2382,6 +2382,7 @@
     && ((CODE_ADDRESS_RANGE >> (MMAP_FIXED_ADDRESS_HIGHEST_BIT-6)) == 0)       \
     && ((MALLOC_ADDRESS_RANGE >> (MMAP_FIXED_ADDRESS_HIGHEST_BIT-6)) == 0)     \
     && defined(WIDE_HARD)                                                      \
+    && !(defined(UNIX_LINUX) && defined(S390_64))                              \
     && !defined(NO_SINGLEMAP)                                                  \
     && !defined(MULTITHREAD)
 /* If we have not already excluded TYPECODES, and not WIDE_SOFT,
@@ -2391,6 +2392,7 @@
    CODE_ADDRESS_RANGE and MALLOC_ADDRESS_RANGE (maybe also need to check
    SHLIB_ADDRESS_RANGE and STACK_ADDRESS_RANGE?),
    and we are on a 64-bit platform [2],
+   and we are not on Linux/s390x.
    then pick SINGLEMAP_MEMORY.
    [1] It does not work reliably when address space layout randomization
    is in effect: SINGLEMAP_MEMORY assumes that one can extend an existing
@@ -2422,12 +2424,14 @@
          PSEUDOCODE_ALIGNMENT; this can be harder to achieve.
        TYPECODES is typically a few percent slower than HEAPCODES.
        For portability, choose TYPECODES if possible, and HEAPCODES otherwise.
+       Special case: On Linux/s390x, TYPECODES does not work right so far.
      */
     #if !defined(NO_ADDRESS_SPACE_ASSUMPTIONS) \
         && ((CODE_ADDRESS_RANGE >> 56) == 0)   \
         && ((MALLOC_ADDRESS_RANGE >> 56) == 0) \
         && ((SHLIB_ADDRESS_RANGE >> 56) == 0)  \
-        && ((STACK_ADDRESS_RANGE >> 56) == 0)
+        && ((STACK_ADDRESS_RANGE >> 56) == 0)  \
+        && !(defined(UNIX_LINUX) && defined(S390_64))
       #define TYPECODES
     #else
       #define HEAPCODES
@@ -2621,6 +2625,8 @@
      addresses. But we know that pointers have alignment 8. */
     #if (defined(I80386) && defined(UNIX_LINUX)) || (defined(AMD64) && defined(UNIX_LINUX) && (pointer_bitsize==32)) || (defined(I80386) && defined(UNIX_OPENBSD)) || (defined(I80386) && defined(UNIX_CYGWIN32))
       #define KERNELVOID32_HEAPCODES
+    #elif defined(S390_64) && defined(UNIX_LINUX)
+      #define GENERIC64_HEAPCODES
     #else
       #define ONE_FREE_BIT_HEAPCODES
     #endif
@@ -2940,6 +2946,26 @@
       #define oint_data_len oint_addr_len
       #define oint_data_mask oint_addr_mask
     #endif
+    #if defined(S390_64) && defined(UNIX_LINUX)
+      /* UNIX_LINUX:
+           CODE_ADDRESS_RANGE     0x0000000080000000UL
+           MALLOC_ADDRESS_RANGE   0x0000000081000000UL ... 0x00000000BE000000UL
+           SHLIB_ADDRESS_RANGE    0x000003FFFD000000UL
+           STACK_ADDRESS_RANGE    0x000003FFFF000000UL
+           Virtual address limit (= 2^(MMAP_FIXED_ADDRESS_HIGHEST_BIT+1)-1)
+                                  0x001FFFFFFFFFFFFFUL
+         Bits 63..56 = type code, Bits 55..0 = address */
+      /* FIXME: This parameterization does not actually work. */
+      #define oint_type_shift 56
+      #define oint_type_len 8
+      #define oint_type_mask 0xFF00000000000000UL
+      #define oint_addr_shift 0
+      #define oint_addr_len 56
+      #define oint_addr_mask 0x00FFFFFFFFFFFFFFUL
+      #define oint_data_shift oint_addr_shift
+      #define oint_data_len oint_addr_len
+      #define oint_data_mask oint_addr_mask
+    #endif
   #endif
 #elif defined(WIDE_SOFT)
   /* separate one 32-bit word for typcode and address. */
diff -r 92d52f80a4e4 -r 5a3a37e01f03 src/spvw.d
--- a/src/spvw.d	Mon Aug 21 00:00:39 2017 +0200
+++ b/src/spvw.d	Mon Aug 21 01:59:25 2017 +0200
@@ -3169,6 +3169,11 @@
          and there is room from 0x080000000000 to 0x380000000000. */
       mem.heaps[0].heap_limit = 0x080000000000UL;
       mem.heaps[1].heap_limit = 0x380000000000UL;
+      #elif defined(UNIX_LINUX) && defined(S390_64)
+      /* On Linux/s390x, the available addresses are in the range 0..2^53,
+         and there is room from 0x008000000000 to 0x038000000000. */
+      mem.heaps[0].heap_limit = 0x008000000000UL;
+      mem.heaps[1].heap_limit = 0x038000000000UL;
       #elif defined(UNIX_FREEBSD) && defined(AMD64)
       mem.heaps[0].heap_limit = 0x001000000000UL;
       mem.heaps[1].heap_limit = 0x700000000000UL;
@@ -3228,6 +3233,13 @@
       mem.heaps[0].heap_hardlimit = 0x200000000000UL;
       mem.heaps[1].heap_limit = 0x200000000000UL;
       mem.heaps[1].heap_hardlimit = 0x380000000000UL;
+      #elif defined(UNIX_LINUX) && defined(S390_64)
+      /* On Linux/s390x, the available addresses are in the range 0..2^53,
+         and there is room from 0x008000000000 to 0x038000000000. */
+      mem.heaps[0].heap_limit = 0x008000000000UL;
+      mem.heaps[0].heap_hardlimit = 0x020000000000UL;
+      mem.heaps[1].heap_limit = 0x020000000000UL;
+      mem.heaps[1].heap_hardlimit = 0x038000000000UL;
       #elif defined(TYPECODES) && (oint_addr_len+addr_shift > pointer_bitsize)
        #ifdef UNIX_DARWIN
       /* 'vmmap' shows that there is room between the malloc area at 0x01...... or 0x02......
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.