[cmucl-help] CMUCL 18c building on tru64 5.1

Fausto Saporito fausto.saporito at gmail.com
Mon Sep 8 18:28:33 UTC 2014


Hello
I was thinking about the way I fixed the assembler error.
Maybe it's not the correct way... and this could cause the problem in
the assembler file overall...

This is the error:

as -g -Dosf1 -Dalpha -I../../src/lisp  -o alpha-assem.o alpha-assem.s
alpha-assem.s(246) : error : syntax error : last token was 'undefined_tramp'
alpha-assem.s(261) : error : syntax error : last token was 'closure_tramp'

and I fixed changing the .end statement

        .text
        .globl  undefined_tramp
        .ent    undefined_tramp_offset
undefined_tramp = /* ### undefined_tramp_offset-call_into_lisp_LRA*/ 0x140+call_
into_lisp_LRA_page
undefined_tramp_offset:
        call_pal PAL_gentrap
        .long    trap_Error
        /* Number of argument bytes */
        .byte    4
        .byte    UNDEFINED_SYMBOL_ERROR
        /* Escape to create 16bit BE number from following two values */
        .byte    254
        /* SC_OFFSET(sc_DescriptorReg,reg_FDEFN) */
        .byte    (0xe0 + sc_DescriptorReg)
        .byte    2
        .align 2
        .end    undefined_tramp

modifying in .end undefined_tramp_offset

and I did the same for the closure_tramp.

Unfortunately I don't know alpha asm... so maybe someone could check
if this is correct.

thanks,
Fausto


2014-09-08 19:41 GMT+02:00 Fausto Saporito <fausto.saporito at gmail.com>:
> Hello... I fixed the Depends problem... in the GNUMakefile there's -MM
> flag for depend... it seems DEC cc wants just one M...
>
> so -M -E
>
> regards,
> Fausto
>
>
> 2014-09-08 19:16 GMT+02:00 Fausto Saporito <fausto.saporito at gmail.com>:
>> ok, Ray.
>> I'll use 19c from now on.
>>
>> thanks,
>> Fausto
>>
>>
>> 2014-09-08 18:24 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
>>>
>>>
>>>
>>> On Sun, Sep 7, 2014 at 9:42 PM, Fausto Saporito <fausto.saporito at gmail.com>
>>> wrote:
>>>>
>>>> Hello Raymond
>>>>
>>>> I agree with you. I don' want try random version, I'm following what you
>>>> said in a previous message.
>>>>
>>>> More far we are from 18a, worst is.
>>>>
>>>> Now I have a cross compiled kernel core from 19a and 19c
>>>> What do you think ? Are they ok for our purpose or we should get a core
>>>> from 18c or 18d ?
>>>
>>>
>>> If you have a kernel.core from 19a or 19c, let's stay with that. If 19c is
>>> working, let's use 19c since it's more up-to-date.
>>>
>>> Let's figure out why call_into_lisp is crashing.
>>>
>>>>
>>>>
>>>> So we can stick to a specific version and we can continue only with that
>>>> one.
>>>>
>>>> Regards
>>>> Fausto
>>>>
>>>> Il giorno 08/set/2014, alle ore 00:15, Raymond Toy <toy.raymond at gmail.com>
>>>> ha scritto:
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Sep 7, 2014 at 9:25 AM, Fausto Saporito
>>>> <fausto.saporito at gmail.com> wrote:
>>>>>
>>>>> Hello Ray,
>>>>>
>>>>> i'm trying to do a cross-compile with 18e, I copied the scripts from
>>>>> 19a, cause in the 18x src tree they don't exist.
>>>>> It seems all ok, but I got this new error:
>>>>>
>>>>> ;; Loading
>>>>> #p"/home/fausap/CMU/18e/alpha-cross/compiler/generic/new-genesis.x86f".
>>>>> ;
>>>>>
>>>>> ; Warning: This function is undefined:
>>>>> ;   KERNEL::%CLASS-LAYOUT
>>>>>
>>>>> Error in %COERCE-TO-FUNCTION:  the function KERNEL::%CLASS-LAYOUT is
>>>>> undefined.
>>>>
>>>>
>>>> Ah, there were some class layout changes done by Gerd somewhere around
>>>>
>>>> the 18e or 18f time frame.  It might work to just remove those things from
>>>> the bootstrap file or try to get the scripts from release 18e or 18f.
>>>>
>>>> Rather than randomly trying different versions, can we stick to the one
>>>> where you were able to create a kernel.core successfully? (Which version was
>>>> that?) Let's stick to that and see how far we can get with it. I think if we
>>>> can figure out why your debugger session is so different from the assembly
>>>> source, we can make it work. That's gotta be something simple and stupid
>>>> that we're overlooking. I just don't know what it could be.
>>>>
>>>>
>>>>>
>>>>> Restarts:
>>>>>   0: [CONTINUE] Return NIL from load of "cross.lisp".
>>>>>   1: [ABORT   ] Return to Top-Level.
>>>>>
>>>>> Debug  (type H for help)
>>>>>
>>>>> (%COERCE-TO-FUNCTION KERNEL::%CLASS-LAYOUT)
>>>>> Source:
>>>>> ; File: target:code/fdefinition.lisp
>>>>> (ERROR 'UNDEFINED-FUNCTION :NAME NAME)
>>>>>
>>>>> maybe something in setenv-scripts directory is too new...
>>>>>
>>>>> what do you think ?
>>>>>
>>>>> regards,
>>>>> Fausto
>>>>>
>>>>>
>>>>> 2014-09-07 6:35 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
>>>>> > Change :compile-toplevel :load-toplevel :execute to compile load eval.
>>>>> > The
>>>>> > former are the CLHS names previously known as the latter. CMUCL
>>>>> > supports
>>>>> > both. The purpose of the change was to make all of the exported symbols
>>>>> > in
>>>>> > parms.lisp available while cross-compiling. This is why you were
>>>>> > getting
>>>>> > errors about using symbols that weren't exported.
>>>>> >
>>>>> > I think 20d should support the new :compile-toplevel and friends.
>>>>> >
>>>>> > Also, I think 20d might work if you use a lisp that uses 8-big chars
>>>>> > instead
>>>>> > of unicode.  20e would work if you make a small change to
>>>>> > src/compiler/alpha/array.lisp.  On line 137, change :byte to :short.
>>>>> > This
>>>>> > makes Lisp characters be 16-bits long instead of 8.  You'll have to
>>>>> > compile
>>>>> > using a 20e lisp with unicode.
>>>>> >
>>>>> > However, I think it would be best to stay with 18c or 18d to do the
>>>>> > first
>>>>> > cross-compiles.  The farther away we get from 18a, the more changes,
>>>>> > and
>>>>> > it's not clear if the changes were ported to alpha or not.
>>>>> >
>>>>> > We still have to figure out why your debugger session disassembly of
>>>>> > call_into_lisp looks so different from the actual assembly in
>>>>> > alpha-assem.S.
>>>>> >
>>>>> >
>>>>> > On Sat, Sep 6, 2014 at 1:49 PM, Fausto Saporito
>>>>> > <fausto.saporito at gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Hello,
>>>>> >>
>>>>> >> i tried again cross-compiling using the git sources, I saw Ray
>>>>> >> modified something related alpha tree... but it seems cmucl doesn't
>>>>> >> like the line with eval-when
>>>>> >>
>>>>> >> ; Error: Read error in form starting at 1236:
>>>>> >> ;  "(eval-when (:compile-toplevel :load-toplevel :execute)"
>>>>> >> ; End-of-File on #<Stream for file
>>>>> >> "/home/fausap/CMU/cmucl/src/compiler/alpha/parms.lisp">
>>>>> >>
>>>>> >> I tried with 20d and 20e
>>>>> >>
>>>>> >> What am I doing wrong ?
>>>>> >>
>>>>> >> regards,
>>>>> >> Fausto
>>>>> >>
>>>>> >>
>>>>> >> 2014-09-04 23:54 GMT+02:00 Fausto Saporito
>>>>> >> <fausto.saporito at gmail.com>:
>>>>> >> > It's INITIAL-FUNCTION:
>>>>> >> >
>>>>> >> > 0x3028EEE8: %INITIAL-FUNCTION   #x3028EED1
>>>>> >> >
>>>>> >> > so it seems ok...
>>>>> >> >
>>>>> >> >
>>>>> >> > 2014-09-04 22:29 GMT+02:00 Carl Shapiro <carl.shapiro at gmail.com>:
>>>>> >> >> On Thu, Sep 4, 2014 at 9:17 AM, Raymond Toy <toy.raymond at gmail.com>
>>>>> >> >> wrote:
>>>>> >> >>>
>>>>> >> >>> I have to say, I can't really understand this.  The disassembled
>>>>> >> >>> instructions don't seem to match what's in alpha-assem.S.  I'm
>>>>> >> >>> guessing,
>>>>> >> >>> however, that this jsr inst is jumping into the initial_function,
>>>>> >> >>> which
>>>>> >> >>> might be in v0.  But in alpha-assem.S, the instruction looks like
>>>>> >> >>> jsr
>>>>> >> >>> reg_ZERO, (reg_LIP).
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> The map files generated when building a core should help you
>>>>> >> >> translate
>>>>> >> >> a PC
>>>>> >> >> to a function.  I would look to see which function's PC range
>>>>> >> >> encloses
>>>>> >> >> 0x3028eee8.  From there, we can develop a hypothesis about what is
>>>>> >> >> going
>>>>> >> >> wrong.
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Ray
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ray
>>>
>>>


More information about the cmucl-help mailing list