[cmucl-help] 19c alpha [Was Re: CMUCL 18c building on tru64 5.1]
Fausto Saporito
fausto.saporito at gmail.com
Mon Sep 8 22:02:50 UTC 2014
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