[cmucl-help] 19c alpha [Was Re: CMUCL 18c building on tru64 5.1]
Fausto Saporito
fausto.saporito at gmail.com
Mon Sep 8 22:15:50 UTC 2014
... just another bit. In order to have that output I put .set
noreorder in the call_to_lisp definition.
ASM performs a reorder of statements, and with that command we force
to follow the statements as thet are written.
regards,
Fausto
2014-09-09 0:02 GMT+02:00 Fausto Saporito <fausto.saporito at gmail.com>:
> Hello,
>
> another fix in the Config.alpha_osf1, the CPPFLAGS needs a space and
> we have to remove the obsolete option -I- and change it with -iquote.
> So
> CPPFLAGS = -I. -I/usr/include -I$(P1) -iquote
>
> Then, I understood why my previous debug session was so strange.
> I used the "stepi" function, that performs a step-inside, generally
> used to debug inside a function.
> If I use the standard "step" function, I have the debug line-by-line
> equals to the source file:
>
> axpvm01.gitanes.taz> dbx lisp
> dbx version 5.1
> Type 'help' for help.
>
> main: 405 char *core = NULL;
> (dbx) stop in funcall0
> [2] stop in funcall0
> (dbx) run -core kernel.core
> WARNING: startup-code version (3) different from core version (0).
> You may lose big.
> [2] stopped at [funcall0:354 ,0x1201b224] lispobj *args =
> current_control_stack_pointer;
> (dbx) n
> [funcall0:356 ,0x1201b230] return call_into_lisp(function, args, 0);
> (dbx) stepi
>>*[funcall0:356, 0x1201b234] ldq a1, 16(sp)
> (dbx) s
> [call_into_lisp:26 ,0x1201b448] lda sp,-framesize(sp)
> (dbx) s
> [call_into_lisp:27 ,0x1201b44c] stq ra, framesize-8*8(sp)
> (dbx) s
> [call_into_lisp:28 ,0x1201b450] stq s0, framesize-8*7(sp)
> (dbx) s
> [call_into_lisp:29 ,0x1201b454] stq s1, framesize-8*6(sp)
> (dbx) s
> [call_into_lisp:30 ,0x1201b458] stq s2, framesize-8*5(sp)
> (dbx) s
> [call_into_lisp:31 ,0x1201b45c] stq s3, framesize-8*4(sp)
> (dbx) s
> [call_into_lisp:32 ,0x1201b460] stq s4, framesize-8*3(sp)
> (dbx) s
> [call_into_lisp:33 ,0x1201b464] stq s5, framesize-8*2(sp)
> (dbx) s
> [call_into_lisp:34 ,0x1201b468] stq s6, framesize-8*1(sp)
> (dbx) s
> [call_into_lisp:39 ,0x1201b46c] ldil reg_CODE,0
> (dbx) s
> [call_into_lisp:40 ,0x1201b470] ldil reg_FDEFN,0
> (dbx) s
> [call_into_lisp:41 ,0x1201b474] mov a0,reg_LEXENV
> (dbx) s
> [call_into_lisp:42 ,0x1201b478] sll a2,2,reg_NARGS
> (dbx) s
> [call_into_lisp:43 ,0x1201b47c] ldil reg_OCFP,0
> (dbx) s
> [call_into_lisp:44 ,0x1201b480] ldil reg_LRA,0
> (dbx) s
> [call_into_lisp:45 ,0x1201b484] ldil reg_L0,0
> (dbx) s
> [call_into_lisp:46 ,0x1201b488] ldil reg_L1,0
> (dbx) s
> [call_into_lisp:50 ,0x1201b48c] ldil reg_NULL,NIL
> (dbx) s
> [call_into_lisp:55 ,0x1201b494] stl
> zero,foreign_function_call_active
> (dbx) s
> [call_into_lisp:58 ,0x1201b49c] ldl
> reg_ALLOC,current_dynamic_space_free_pointer
> (dbx) s
> [call_into_lisp:59 ,0x1201b4a4] ldl
> reg_BSP,current_binding_stack_pointer
> (dbx) s
> [call_into_lisp:60 ,0x1201b4ac] ldl
> reg_CSP,current_control_stack_pointer
> (dbx) s
> [call_into_lisp:61 ,0x1201b4b4] ldl
> reg_OCFP,current_control_frame_pointer
> (dbx) s
> [call_into_lisp:62 ,0x1201b4bc] mov a1,reg_CFP
> (dbx) s
> [call_into_lisp:65 ,0x1201b4c0] ldil reg_L2,0
> (dbx) s
> [call_into_lisp:70 ,0x1201b4c4] ldl reg_A0,0(reg_CFP)
> (dbx) s
> [call_into_lisp:71 ,0x1201b4c8] ldl reg_A1,4(reg_CFP)
> (dbx) s
> [call_into_lisp:72 ,0x1201b4cc] ldl reg_A2,8(reg_CFP)
> (dbx) s
> [call_into_lisp:73 ,0x1201b4d0] ldl reg_A3,12(reg_CFP)
> (dbx) s
> [call_into_lisp:74 ,0x1201b4d4] ldl reg_A4,16(reg_CFP)
> (dbx) s
> [call_into_lisp:75 ,0x1201b4d8] ldl reg_A5,20(reg_CFP)
> (dbx) s
> [call_into_lisp:78 ,0x1201b4dc] lda
> reg_LRA,call_into_lisp_LRA_page+type_OtherPointer
> (dbx) s
> [call_into_lisp:81 ,0x1201b4e4] ldl
> reg_CODE,CLOSURE_FUNCTION_OFFSET(reg_LEXENV)
> (dbx) s
> [call_into_lisp:82 ,0x1201b4e8] addl
> reg_CODE,6*4-type_FunctionPointer,reg_LIP
> (dbx) s
> [call_into_lisp:85 ,0x1201b4ec] jsr reg_ZERO,(reg_LIP)
> (dbx) stepi
>>*[., 0x30294860] lda s5, -305(v0)
> (dbx) stepi
>>*[., 0x30294864] lda s0, 96(s1)
> (dbx) stepi
>>*[., 0x30294868] bne t7, 0x30295708
> (dbx) stepi
>>*[., 0x3029486c] stl s2, 0(s1)
> (dbx) stepi
>>*[., 0x30294870] stl ra, 4(s1)
> (dbx) stepi
>>*[., 0x30294874] ldl t9, 13(s5)
> (dbx) stepi
>>*[., 0x30294878] bis zero, t9, a0
> (dbx) stepi
>>*[., 0x3029487c] lda t10, 0(zero)
> (dbx) stepi
>>*[., 0x30294880] ldah t10, 0(t10)
> (dbx) stepi
>>*[., 0x30294884] sll t10, 0x20, t10
> (dbx) stepi
>>*[., 0x30294888] lda t10, 0(t10)
> (dbx) stepi
>>*[., 0x3029488c] ldah t10, 0(t10)
> (dbx) stepi
>>*[., 0x30294890] lda a1, 0(zero)
> (dbx) stepi
>>*[., 0x30294894] ldah a1, 0(a1)
> (dbx) stepi
>>*[., 0x30294898] sll a1, 0x20, a1
> (dbx) stepi
>>*[., 0x3029489c] lda a1, 0(a1)
> (dbx) stepi
>>*[., 0x302948a0] ldah a1, 0(a1)
> (dbx) stepi
>>*[., 0x302948a4] lda sp, -16(sp)
> (dbx) stepi
>>*[., 0x302948a8] jsr v0, (a1), 0x302948ac
> (dbx) stepi
>
> warning: breakpoint location cannot be written
> signal Segmentation fault at
> warning: PC value 0x0 not valid, trying RA
>> [., 0x10007] bgt t10, 0x117d1f
> (dbx)
>
> In lisp.map I can confirm that 0x30294860 is %INITIAL-FUNCTION, but I
> cannot find any reference to 0x302948ac...
>
> So this could be the problem.
>
> regards,
> Fausto
>
>
> 2014-09-08 21:41 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
>> On Mon, Sep 8, 2014 at 10:41 AM, Fausto Saporito <fausto.saporito at gmail.com>
>> wrote:
>>
>>> 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
>>>
>>>
>> Starting a new thread....
>>
>> If we're standardizing on 19c, I'll try to make a branch from 19c to keep
>> track of this development work, so we don't lose it.
>>
>> It's probably worth while for me to get the github mirror of cmucl actually
>> working.
>>
>>
>>
>>
>>> 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
>>> >>
>>> >>
>>>
>> _______________________________________________
>> cmucl-help mailing list
>> cmucl-help at cmucl.cons.org
>> http://lists.zs64.net/mailman/listinfo/cmucl-help
More information about the cmucl-help
mailing list