[cmucl-help] 19c alpha [Was Re: CMUCL 18c building on tru64 5.1]
Raymond Toy
toy.raymond at gmail.com
Tue Sep 9 03:51:42 UTC 2014
On Mon, Sep 8, 2014 at 3:02 PM, Fausto Saporito <fausto.saporito at gmail.com>
wrote:
> 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
>
Not sure what that 0x302948ac is, but a1 should probably be the address of
call_into_c. I think this part of the code is trying to call debug_print
which is a C function, so the address of debug_print must be in one of the
registers, and a1 should be call_into_c.
Can you check that?
I'll have to do some more digging into the alpha instruction set and also
the alpha ABI to know what these things are.
Also, could you send us a copy of <alpha/regdef.h>? I think that is the
header file that defines the symbolic names of the registers.
Thanks,
> (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
>
--
Ray
More information about the cmucl-help
mailing list