Re: CMUCL 18c building on tru64 5.1
Fausto Saporito <[email protected]> Thu, 4 Sep 2014 00:42:24 +0200
| Newsgroups | gmane.lisp.cmucl.general |
|---|---|
| Message-ID | <CAF1zXhkvQC9LQ4prrhLLwL2=DtZ4s6caTXwi07DfDpf6kBJM7g@mail.gmail.com> |
Hello Raymond, I have a doubt... I tried to compile the lisp frontend with gcc (under Tru64)... I suppose the Config file has been made with gcc in mind... the -I- in the CPPFLAGS is gcc syntax...not DECC Also gmake doesn't complain about the depends generated by gcc. I have only gcc4.x at the moment, and maybe is too new... I have an error compiling src/lisp/interrupt.c at line 644: ../../src/lisp/interrupt.c:644: error: lvalue required as left operand of assignment That line is : SC_NPC(context) = SC_PC(context) + 4; maybe it could be SC_PC(context) = SC_PC(context) + 4; this line interpreted only if not x86. SC_NPC is only used in that line... so it's quite strange. regards fausto 2014-09-03 22:13 GMT+02:00 Raymond Toy <[email protected]>: > > > > On Wed, Sep 3, 2014 at 12:52 PM, Fausto Saporito <[email protected]> > wrote: >> >> Hello Ray, >> >> the sigsegv happens calling funcall0(initial_function)... at line 702 >> in main function. >> >> ladebug under Tru64 is very cool ;-) >> >> now... what is the purpose of funcall0 ? > > > This is the difficult fun part. > > funcall0 is calling the Lisp function given in initial_function with 0 > arguments. If it's actually crashing at that line, then does > initial_function look valid? It should be an address somewhere in the heap > and the least 3 bits should be 001. > > If this is not true, then either the creation of kernel.core is wrong or > loading the core is wrong. (The initial_function is in the core file. > Somewhere. I don't remember exactly.) > > >> >> >> regards, >> Fausto >> >> >> >> 2014-09-03 19:08 GMT+02:00 Raymond Toy <[email protected]>: >> > >> > >> > >> > On Wed, Sep 3, 2014 at 9:29 AM, Fausto Saporito >> > <[email protected]> >> > wrote: >> >> >> >> Hello Ray, >> >> >> >> in the alpha-cross and alpha-target log... there are no errors. it >> >> compiles like a knive in the butter :) >> > >> > >> > Cool! >> > >> >> >> >> >> >> But maybe "interrupt_handle_now" could refers to a feature we excluded >> >> from the build. >> >> >> >> this is the "back" output >> >> >> >> ldb> back >> >> Backtrace: >> >> <Frame 0x50000000 [interrupted], CODE: 0x3029472F, %INITIAL-FUNCTION, >> >> <no LRA>, PC: 0xcfd6b7b8> >> > >> > >> > Ok, that's not very helpful. You have to break out your debugger to >> > figure >> > out why you're getting signal 11. (segv?) >> > >> >> >> >> >> >> About 18c test, can I use the 19c binaries (on linux) to cross-compile >> >> a 18c, or do I have to install a 18c linux binaries ? >> > >> > >> > It's best to use the same version, so use 18c binaries. >> > >> > Good luck! >> > -- >> > Ray >> > >> >> >> >> >> >> thanks, >> >> Fausto >> >> >> >> 2014-09-03 18:24 GMT+02:00 Raymond Toy <[email protected]>: >> >> > >> >> > >> >> > >> >> > On Wed, Sep 3, 2014 at 4:57 AM, Fausto Saporito >> >> > <[email protected]> >> >> > wrote: >> >> >> >> >> >> ok.. I fixed the version problem: created a file, in >> >> >> alpha-target/lisp >> >> >> directory, "version" with "-1" in it. >> >> >> Now the version matches with kernel.core (version 0). >> >> >> >> >> >> But it seems a needed feature is missing: >> >> >> >> >> >> axpvm01.gitanes.taz> lisp -core kernel.core >> >> >> interrupt_handle_now: No handler for signal 11? >> >> >> LDB monitor >> >> >> >> >> >> ldb> >> >> >> >> >> > >> >> > This is really great! But now comes the hard part. >> >> > >> >> > First, I would check the logs for any errors and see if they're >> >> > relevant. >> >> > Post the errors here. >> >> > >> >> > Second, from ldb you can try "back" to get a backtrace. That might >> >> > have >> >> > pointers to what might have gone wrong. >> >> > >> >> > Third, if none of the above work, you'll have to get out your >> >> > debugger >> >> > and >> >> > see what is causing signal 11. This is the hard part. >> >> > >> >> > Since it seems you can successfully cross-compile from 19c, perhaps >> >> > it >> >> > would >> >> > be easiest to go back farther and try again with 18c or something. It >> >> > might >> >> > be easier to get something going and then we can think about getting >> >> > alpha >> >> > running on a more up-to-date version of the code. >> >> > >> >> > Good luck! >> >> > >> >> >> >> >> >> >> >> >> >> >> >> 2014-09-03 13:39 GMT+02:00 Fausto Saporito >> >> >> <[email protected]>: >> >> >> > Hello all, >> >> >> > >> >> >> > ok... this is a real blocking error: >> >> >> > >> >> >> > axpvm01.gitanes.taz> alpha-target/lisp/lisp -core >> >> >> > alpha-target/lisp/kernel.core >> >> >> > WARNING: startup-code version (2) different from core version (0). >> >> >> > You may lose big. >> >> >> > interrupt_handle_now: No handler for signal 11? >> >> >> > LDB monitor >> >> >> > ldb> quit >> >> >> > Really quit? [y] >> >> >> > >> >> >> > and really I cannot understand the reason. >> >> >> > kernel.core has been generated with the same sources of the lisp >> >> >> > frontend! Why there's this version mismatch ? >> >> >> > >> >> >> > I changed internals.h cause it was totally wrong (feature list >> >> >> > section) and I copied them from internals.inc ... is it correct ? >> >> >> > But internals.inc has much more features than cross.lisp, maybe >> >> >> > this >> >> >> > could be the problem... >> >> >> > >> >> >> > FEATURE_CMU18E = 1 >> >> >> > FEATURE_CMU18 = 1 >> >> >> > FEATURE_BSD = 1 >> >> >> > FEATURE_OSF1 = 1 >> >> >> > FEATURE_ALPHA = 1 >> >> >> > FEATURE_CMU = 1 >> >> >> > FEATURE_IEEE_FLOATING_POINT = 1 >> >> >> > FEATURE_ANSI_CL = 1 >> >> >> > FEATURE_COMMON_LISP = 1 >> >> >> > FEATURE_COMMON = 1 >> >> >> > FEATURE_HASH_NEW = 1 >> >> >> > FEATURE_RANDOM_MT19937 = 1 >> >> >> > FEATURE_UNIX = 1 >> >> >> > FEATURE_RELATIVE_PACKAGE_NAMES = 1 >> >> >> > FEATURE_MODULAR_ARITH = 1 >> >> >> > FEATURE_CONSERVATIVE_FLOAT_TYPE = 1 >> >> >> > FEATURE_PYTHON = 1 >> >> >> > FEATURE_CMU19C = 1 >> >> >> > FEATURE_CMU19 = 1 >> >> >> > FEATURE_PCL = 1 >> >> >> > <----- >> >> >> > FEATURE_PORTABLE_COMMONLOOPS = 1 >> >> >> > FEATURE_PCL_STRUCTURES = 1 >> >> >> > FEATURE_GERDS_PCL = 1 >> >> >> > FEATURE_BOOTSTRAP = 1 >> >> >> > FEATURE_NO_PCL = 1 >> >> >> > <----- >> >> >> > FEATURE_NO_CLX = 1 >> >> >> > FEATURE_NO_CLM = 1 >> >> >> > FEATURE_NO_HEMLOCK = 1 >> >> >> > FEATURE_LITTLE_ENDIAN = 1 >> >> >> > >> >> >> > Is it correct >> >> >> > >> >> >> > FEATURE_PCL = 1 >> >> >> > >> >> >> > then >> >> >> > >> >> >> > FEATURE_NOPCL = 1 >> >> >> > >> >> >> > ??? >> >> >> > >> >> >> > regards, >> >> >> > Fausto >> >> >> > >> >> >> > 2014-09-03 13:13 GMT+02:00 Fausto Saporito >> >> >> > <[email protected]>: >> >> >> >> This is trivial .. I suppose. >> >> >> >> I'm using standard Tru64 5.1b C compiler, but it seems generates >> >> >> >> a >> >> >> >> Depend file gmake doesn't like too much :-) >> >> >> >> I'm using gmake 3.80, is there a mandatory version ? >> >> >> >> >> >> >> >> gmake: Entering directory >> >> >> >> `/usr/users/fausap/CMU/alpha-target/lisp' >> >> >> >> Depends:454: *** missing separator. Stop. >> >> >> >> gmake: Leaving directory >> >> >> >> `/usr/users/fausap/CMU/alpha-target/lisp' >> >> >> >> >> >> >> >> this code starts at line 454 >> >> >> >> >> >> >> >> struct array { >> >> >> >> lispobj header; >> >> >> >> lispobj fill_pointer; >> >> >> >> lispobj fill_pointer_p; >> >> >> >> lispobj elements; >> >> >> >> lispobj data; >> >> >> >> lispobj displacement; >> >> >> >> lispobj displaced_p; >> >> >> >> lispobj dimensions[1]; >> >> >> >> }; >> >> >> >> >> >> >> >> thanks, >> >> >> >> Fausto >> >> >> >> >> >> >> >> 2014-09-03 11:39 GMT+02:00 Fausto Saporito >> >> >> >> <[email protected]>: >> >> >> >>> Ohhhh ... BIG NeWS! >> >> >> >>> >> >> >> >>> 19c works! Cross compiling was fine. >> >> >> >>> Now if I understood well, I have to move all the alpha-target >> >> >> >>> directory in Tru64 and recompile... correct ? >> >> >> >>> Using src/tools/build-world.sh script ? >> >> >> >>> >> >> >> >>> thanks >> >> >> >>> Fausto >> >> >> >>> >> >> >> >>> >> >> >> >>> 2014-09-03 11:28 GMT+02:00 Fausto Saporito >> >> >> >>> <[email protected]>: >> >> >> >>>> Hello all, >> >> >> >>>> >> >> >> >>>> I saw there're some patches for 19c and 19d and I found how to >> >> >> >>>> apply >> >> >> >>>> them. >> >> >> >>>> The question is: how can I update the lisp.core ? Is it needed >> >> >> >>>> ? >> >> >> >>>> Or >> >> >> >>>> do >> >> >> >>>> I have to load each time those patches ? >> >> >> >>>> >> >> >> >>>> thanks, >> >> >> >>>> Fausto >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> 2014-09-03 8:41 GMT+02:00 Fausto Saporito >> >> >> >>>> <[email protected]>: >> >> >> >>>>> Hello Ray, >> >> >> >>>>> >> >> >> >>>>> no luck with 19d. But maybe it has the double-double support >> >> >> >>>>> too... >> >> >> >>>>> >> >> >> >>>>> I have the same errors, but instead of sigsegv at the end, I >> >> >> >>>>> got >> >> >> >>>>> a >> >> >> >>>>> stack overflow: >> >> >> >>>>> >> >> >> >>>>> Control stack overflow >> >> >> >>>>> [Condition of type STACK-OVERFLOW] >> >> >> >>>>> >> >> >> >>>>> Restarts: >> >> >> >>>>> 0: [CONTINUE] Blow this file >> >> >> >>>>> 1: Return NIL from load of >> >> >> >>>>> "target:tools/worldcom". >> >> >> >>>>> 2: [ABORT ] Return to Top-Level. >> >> >> >>>>> >> >> >> >>>>> Debug (type H for help) >> >> >> >>>>> >> >> >> >>>>> (YELLOW-ZONE-HIT) >> >> >> >>>>> Source: >> >> >> >>>>> ; File: target:code/interr.lisp >> >> >> >>>>> (ERROR 'STACK-OVERFLOW) >> >> >> >>>>> >> >> >> >>>>> and in compile-compiler.log I found again a DOUBLE-DOUBLE >> >> >> >>>>> reference: >> >> >> >>>>> >> >> >> >>>>> ; Comment: $Header: >> >> >> >>>>> /project/cmucl/cvsroot/src/compiler/new-assem.lisp,v 1.34 >> >> >> >>>>> 2004/08/02 >> >> >> >>>>> 16:04:42 cwang Exp $ >> >> >> >>>>> >> >> >> >>>>> ; Compiling DEFUN SEGMENT-MAP-OUTPUT: >> >> >> >>>>> >> >> >> >>>>> Bound is not *, a DOUBLE-DOUBLE-FLOAT or a list of a >> >> >> >>>>> DOUBLE-DOUBLE-FLOAT: 0 >> >> >> >>>>> >> >> >> >>>>> Aborting... >> >> >> >>>>> >> >> >> >>>>> I'll try with 19c >> >> >> >>>>> >> >> >> >>>>> 2014-09-03 8:29 GMT+02:00 Fausto Saporito >> >> >> >>>>> <[email protected]>: >> >> >> >>>>>> Hello Ray, >> >> >> >>>>>> >> >> >> >>>>>> I started with 19d, but I have this strange error: >> >> >> >>>>>> >> >> >> >>>>>> ; Error: (during macroexpansion) >> >> >> >>>>>> ; >> >> >> >>>>>> ; Error in function META-SC-OR-LOSE: >> >> >> >>>>>> ; DOUBLE-DOUBLE-REG is not a defined storage class. >> >> >> >>>>>> ; ; >> >> >> >>>>>> >> >> >> >>>>>> ; Error: (during macroexpansion) >> >> >> >>>>>> ; >> >> >> >>>>>> ; Error in function META-SC-OR-LOSE: >> >> >> >>>>>> ; COMPLEX-DOUBLE-DOUBLE-REG is not a defined storage >> >> >> >>>>>> class. >> >> >> >>>>>> >> >> >> >>>>>> but in 19d there shouldn't be support for DOUBLE-DOUBLE ... >> >> >> >>>>>> correct >> >> >> >>>>>> ? >> >> >> >>>>>> >> >> >> >>>>>> I'm using 19d binaries to cross-build 19d >> >> >> >>>>>> >> >> >> >>>>>> 2014-09-03 4:17 GMT+02:00 Raymond Toy >> >> >> >>>>>> <[email protected]>: >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> On Tue, Sep 2, 2014 at 4:53 PM, Fausto Saporito >> >> >> >>>>>>> <[email protected]> >> >> >> >>>>>>> wrote: >> >> >> >>>>>>>> >> >> >> >>>>>>>> Hello Raymond, >> >> >> >>>>>>>> >> >> >> >>>>>>>> thanks for these hints about cross.lisp >> >> >> >>>>>>>> I put in the proper section the unwanted feature. >> >> >> >>>>>>>> >> >> >> >>>>>>>> So, if I force the redefinition of those symbols at the end >> >> >> >>>>>>>> of >> >> >> >>>>>>>> alpha-cross compiling phase, alpha-target starts but I >> >> >> >>>>>>>> noticed >> >> >> >>>>>>>> this >> >> >> >>>>>>>> error among the others: >> >> >> >>>>>>>> >> >> >> >>>>>>>> ; File: >> >> >> >>>>>>>> /home/fausap/CMUCL/git-ver/cmucl/src/code/lispinit.lisp >> >> >> >>>>>>>> >> >> >> >>>>>>>> ; In: DEFUN SLEEP >> >> >> >>>>>>>> >> >> >> >>>>>>>> ; (ERROR 'SIMPLE-TYPE-ERROR >> >> >> >>>>>>>> ; :FORMAT-CONTROL "Invalid argument to SLEEP: >> >> >> >>>>>>>> ~S.~%~ >> >> >> >>>>>>>> ; Must be a non-negative, non-complex number." >> >> >> >>>>>>>> ; :FORMAT-ARGUMENTS ...) >> >> >> >>>>>>>> ; Note: Deleting unreachable code. >> >> >> >>>>>>>> ; >> >> >> >>>>>>>> >> >> >> >>>>>>>> DOUBLE-DOUBLE-FLOAT fell through ECASE expression. >> >> >> >>>>>>>> Wanted one of (REAL FLOAT OR SINGLE-FLOAT DOUBLE-FLOAT >> >> >> >>>>>>>> RATIONAL >> >> >> >>>>>>>> INTEGER). >> >> >> >>>>>>>> >> >> >> >>>>>>>> it's very strange... I disabled double-double... why I have >> >> >> >>>>>>>> this >> >> >> >>>>>>>> error ? >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> I think it's a mismatch between what the cross compiler has >> >> >> >>>>>>> and >> >> >> >>>>>>> what the >> >> >> >>>>>>> host compiler has. I've never figured this out. >> >> >> >>>>>>> >> >> >> >>>>>>> So, I think it's best to start with a lisp without >> >> >> >>>>>>> double-double >> >> >> >>>>>>> support. >> >> >> >>>>>>> >> >> >> >>>>>>> Support for double-double was apparently done by 19e, so >> >> >> >>>>>>> your >> >> >> >>>>>>> best >> >> >> >>>>>>> bet is to >> >> >> >>>>>>> do a checkout from 19d. I think everything that you've done >> >> >> >>>>>>> up >> >> >> >>>>>>> to >> >> >> >>>>>>> now still >> >> >> >>>>>>> applies. >> >> >> >>>>>>> >> >> >> >>>>>>> Once that is done, we can consider adding double-double for >> >> >> >>>>>>> alpha. >> >> >> >>>>>>> It's >> >> >> >>>>>>> relatively easy, but you'll have to write a bunch of vops. >> >> >> >>>>>>> They >> >> >> >>>>>>> can probably >> >> >> >>>>>>> be copied almost verbatim from the sparc or ppc ports with >> >> >> >>>>>>> small >> >> >> >>>>>>> changes in >> >> >> >>>>>>> the actual instructions. >> >> >> >>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> This is my features list in cross.lisp (I removed >> >> >> >>>>>>>> extern-alien-name, >> >> >> >>>>>>>> fixup, etc... I don't know what they are doing... so maybe >> >> >> >>>>>>>> I >> >> >> >>>>>>>> can >> >> >> >>>>>>>> put >> >> >> >>>>>>>> back later) >> >> >> >>>>>>>> >> >> >> >>>>>>>> ;;; Cross-compile script to build a alpha core using x86 as >> >> >> >>>>>>>> the >> >> >> >>>>>>>> ;;; compiling system. This needs work! >> >> >> >>>>>>>> >> >> >> >>>>>>>> (in-package :cl-user) >> >> >> >>>>>>>> >> >> >> >>>>>>>> ;;; Rename the X86 package and backend so that new-backend >> >> >> >>>>>>>> does >> >> >> >>>>>>>> the >> >> >> >>>>>>>> ;;; right thing. >> >> >> >>>>>>>> (rename-package "X86" "OLD-X86" '("OLD-VM")) >> >> >> >>>>>>>> (setf (c:backend-name c:*native-backend*) "OLD-X86") >> >> >> >>>>>>>> >> >> >> >>>>>>>> (c::new-backend "ALPHA" >> >> >> >>>>>>>> ;; Features to add here >> >> >> >>>>>>>> '(:alpha >> >> >> >>>>>>>> :relative-package-names ; Relative package >> >> >> >>>>>>>> names >> >> >> >>>>>>>> from >> >> >> >>>>>>>> Allegro >> >> >> >>>>>>>> :conservative-float-type >> >> >> >>>>>>>> :hash-new >> >> >> >>>>>>>> :random-mt19937 ; MT-19937 >> >> >> >>>>>>>> generator >> >> >> >>>>>>>> :cmu ; Announce this is >> >> >> >>>>>>>> CMUCL >> >> >> >>>>>>>> :cmu20 :cmu20b ; Current version >> >> >> >>>>>>>> identifier >> >> >> >>>>>>>> :osf1 >> >> >> >>>>>>>> :bsd >> >> >> >>>>>>>> :unix >> >> >> >>>>>>>> ) >> >> >> >>>>>>>> ;; Features to remove from current *features* here >> >> >> >>>>>>>> '(:sparc-v8 :sparc-v7 :sparc-v9 :sparc >> >> >> >>>>>>>> ;; Other architectures we aren't using. Particularly >> >> >> >>>>>>>> important >> >> >> >>>>>>>> ;; to get rid of sse2 and x87 so we don't accidentally >> >> >> >>>>>>>> try >> >> >> >>>>>>>> to >> >> >> >>>>>>>> ;; compile the x87/sse2 float support on sparc, which >> >> >> >>>>>>>> won't >> >> >> >>>>>>>> work. >> >> >> >>>>>>>> :x86 :x86-bootstrap :sse2 :x87 :i486 >> >> >> >>>>>>>> :mips :complex-fp-vops >> >> >> >>>>>>>> ;; Really old stuff that should have been removed long >> >> >> >>>>>>>> ago. >> >> >> >>>>>>>> :propagate-fun-type :propagate-float-type >> >> >> >>>>>>>> :constrain-float-type >> >> >> >>>>>>>> :double-double >> >> >> >>>>>>>> :linkage-table >> >> >> >>>>>>>> :stack-checking ; Throw error if we >> >> >> >>>>>>>> run >> >> >> >>>>>>>> out of >> >> >> >>>>>>>> stack >> >> >> >>>>>>>> :heap-overflow-check ; Throw error if we >> >> >> >>>>>>>> run >> >> >> >>>>>>>> out of >> >> >> >>>>>>>> ; heap (This >> >> >> >>>>>>>> requires >> >> >> >>>>>>>> gencgc!) >> >> >> >>>>>>>> :gencgc ; Generational GC >> >> >> >>>>>>>> :modular-arith ; Modular >> >> >> >>>>>>>> arithmetic >> >> >> >>>>>>>> :executable >> >> >> >>>>>>>> ;; Other OSes were not using >> >> >> >>>>>>>> :openbsd :freebsd :glibc2 :linux :mach-o :darwin >> >> >> >>>>>>>> :sunos >> >> >> >>>>>>>> :svr4 >> >> >> >>>>>>>> :solaris :sun4 >> >> >> >>>>>>>> :pentium >> >> >> >>>>>>>> :long-float >> >> >> >>>>>>>> :new-random >> >> >> >>>>>>>> :small >> >> >> >>>>>>>> :mp)) >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> One last thing: remove :alien-callback too. Alpha doesn't >> >> >> >>>>>>> support >> >> >> >>>>>>> that. >> >> >> >>>>>>> >> >> >> >>>>>>> Hopefully this will get us farther along.... >> >> >> >>>>>>> >> >> >> >>>>>>> -- >> >> >> >>>>>>> Ray >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> > >> >> > >> > >> > > > _______________________________________________ cmucl-help mailing list [email protected] http://lists.zs64.net/mailman/listinfo/cmucl-help