[cmucl-help] CMUCL 18c building on tru64 5.1
Raymond Toy
toy.raymond at gmail.com
Thu Sep 4 16:17:40 UTC 2014
On Thu, Sep 4, 2014 at 3:46 AM, Fausto Saporito <fausto.saporito at gmail.com>
wrote:
> Hello,
>
> this is the debug session of alpha-assem.s, specifically call_to_lisp
> function:
>
> (dbx) stop in funcall0
> [2] stop in funcall0
> (dbx) run -core kernel.core
> WARNING: startup-code version (6) different from core version (0).
> You may lose big.
> [2] stopped at [funcall0:315 ,0x1202df14] lispobj *args =
> current_control_stack_pointer;
> (dbx) n
> [funcall0:317 ,0x1202df20] return call_into_lisp(function, args, 0);
> (dbx) stepi
> >*[funcall0:317, 0x1202df24] ldq a1, 16(sp)
> (dbx) stepi
> >*[funcall0:317, 0x1202df28] bis zero, zero, a2
> (dbx) stepi
> >*[funcall0:317, 0x1202df2c] ldq_u zero, 0(sp)
> (dbx) stepi
> >*[funcall0:317, 0x1202df30] bsr ra, call_into_lisp+0x8(line 54)
> (dbx) stepi
> >*[call_into_lisp:54, 0x1202e138] ldah at, 511(gp)
> (dbx) stepi
> >*[call_into_lisp:25, 0x1202e13c] lda sp, -64(sp)
> (dbx) stepi
> >*[call_into_lisp:28, 0x1202e140] stq s1, 16(sp)
> (dbx) stepi
> >*[call_into_lisp:61, 0x1202e144] bis a1, a1, s1
> (dbx) stepi
> >*[call_into_lisp:29, 0x1202e148] stq s2, 24(sp)
> (dbx) stepi
> >*[call_into_lisp:42, 0x1202e14c] bis zero, zero, s2
> (dbx) stepi
> >*[call_into_lisp:30, 0x1202e150] stq s3, 32(sp)
> (dbx) stepi
> >*[call_into_lisp:45, 0x1202e154] bis zero, zero, t12
> (dbx) stepi
> >*[call_into_lisp:31, 0x1202e158] stq s4, 40(sp)
> (dbx) stepi
> >*[call_into_lisp:40, 0x1202e15c] bis a0, a0, s4
> (dbx) stepi
> >*[call_into_lisp:32, 0x1202e160] stq s5, 48(sp)
> (dbx) stepi
> >*[call_into_lisp:38, 0x1202e164] bis zero, zero, s5
> (dbx) stepi
> >*[call_into_lisp:33, 0x1202e168] stq s6, 56(sp)
> (dbx) stepi
> >*[call_into_lisp:49, 0x1202e16c] ldah s6, 10240(zero)
> (dbx) stepi
> >*[call_into_lisp:27, 0x1202e170] stq s0, 8(sp)
> (dbx) stepi
> >*[call_into_lisp:49, 0x1202e174] lda s6, 11(s6)
> (dbx) stepi
> >*[call_into_lisp:26, 0x1202e178] stq ra, 0(sp)
> (dbx) stepi
> >*[call_into_lisp:43, 0x1202e17c] bis zero, zero, ra
> (dbx) stepi
> >*[call_into_lisp:54, 0x1202e180] stl zero, 23488(at)
> (dbx) stepi
> >*[call_into_lisp:77, 0x1202e184] ldah ra, 1(zero)
> (dbx) stepi
> >*[call_into_lisp:57, 0x1202e188] ldah at, 511(gp)
> (dbx) stepi
> >*[call_into_lisp:44, 0x1202e18c] bis zero, zero, t6
> (dbx) stepi
> >*[call_into_lisp:80, 0x1202e190] ldl s5, 3(s4)
> (dbx) stepi
> >*[call_into_lisp:77, 0x1202e194] lda ra, 7(ra)
> (dbx) stepi
> >*[call_into_lisp:57, 0x1202e198] ldl t8, 23424(at)
> (dbx) stepi
> >*[call_into_lisp:39, 0x1202e19c] bis zero, zero, t9
> (dbx) stepi
> >*[call_into_lisp:58, 0x1202e1a0] ldah at, 511(gp)
> (dbx) stepi
> >*[call_into_lisp:81, 0x1202e1a4] addl s5, 0x17, v0
> (dbx) stepi
> >*[call_into_lisp:69, 0x1202e1a8] ldl t0, 0(s1)
> (dbx) stepi
> >*[call_into_lisp:41, 0x1202e1ac] s4addq a2, 0, t7
> (dbx) stepi
> >*[call_into_lisp:58, 0x1202e1b0] ldl s3, 23480(at)
> (dbx) stepi
> >*[call_into_lisp:59, 0x1202e1b4] ldah at, 511(gp)
> (dbx) stepi
> >*[call_into_lisp:70, 0x1202e1b8] ldl t1, 4(s1)
> (dbx) stepi
> >*[call_into_lisp:59, 0x1202e1bc] ldl s0, 23464(at)
> (dbx) stepi
> >*[call_into_lisp:60, 0x1202e1c0] ldah at, 511(gp)
> (dbx) stepi
> >*[call_into_lisp:71, 0x1202e1c4] ldl t2, 8(s1)
> (dbx) stepi
> >*[call_into_lisp:60, 0x1202e1c8] ldl s2, 23472(at)
> (dbx) stepi
> >*[call_into_lisp:64, 0x1202e1cc] bis zero, zero, at
> (dbx) stepi
> >*[call_into_lisp:72, 0x1202e1d0] ldl t3, 12(s1)
> (dbx) stepi
> >*[call_into_lisp:73, 0x1202e1d4] ldl t4, 16(s1)
> (dbx) stepi
> >*[call_into_lisp:74, 0x1202e1d8] ldl t5, 20(s1)
> (dbx) stepi
> >*[call_into_lisp:84, 0x1202e1dc] jsr zero, (v0), 0x1202e1e0
>
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).
> (dbx) stepi
> >*[., 0x3028eee8] lda s5, -305(v0)
> (dbx) stepi
> >*[., 0x3028eeec] lda s0, 96(s1)
> (dbx) stepi
> >*[., 0x3028eef0] bne t7, 0x3028fd90
> (dbx) stepi
> >*[., 0x3028eef4] stl s2, 0(s1)
> (dbx) stepi
> >*[., 0x3028eef8] stl ra, 4(s1)
> (dbx) stepi
> >*[., 0x3028eefc] ldl t9, 13(s5)
> (dbx) stepi
> >*[., 0x3028ef00] bis zero, t9, a0
> (dbx) stepi
> >*[., 0x3028ef04] lda t10, 0(zero)
> (dbx) stepi
> >*[., 0x3028ef08] ldah t10, 0(t10)
> (dbx) stepi
> >*[., 0x3028ef0c] sll t10, 0x20, t10
> (dbx) stepi
> >*[., 0x3028ef10] lda t10, 0(t10)
> (dbx) stepi
> >*[., 0x3028ef14] ldah t10, 0(t10)
> (dbx) stepi
> >*[., 0x3028ef18] lda a1, 0(zero)
> (dbx) stepi
> >*[., 0x3028ef1c] ldah a1, 0(a1)
> (dbx) stepi
> >*[., 0x3028ef20] sll a1, 0x20, a1
> (dbx) stepi
> >*[., 0x3028ef24] lda a1, 0(a1)
> (dbx) stepi
> >*[., 0x3028ef28] ldah a1, 0(a1)
> (dbx) stepi
> >*[., 0x3028ef2c] lda sp, -16(sp)
> (dbx) stepi
> >*[., 0x3028ef30] jsr v0, (a1), 0x3028ef34
> (dbx) stepi
>
I think at this point you are in Lisp, running lisp code. I'm guessing
this jsr is trying to do %primitive print to print "In initial-function,
and running."
>
> warning: breakpoint location cannot be written
> signal Segmentation fault at
> warning: PC value 0x0 not valid, trying RA
> > [., 0x10007] bgt t10, 0x117d1f
> (dbx)
>
> 2014-09-04 9:27 GMT+02:00 Carl Shapiro <carl.shapiro at gmail.com>:
> > You might want to check the definitions of structures like struct, struct
> > timeval, and struct sigcontext against what is unix.lisp. These
> structures
> > evolved to have wider fields for various things though I no longer
> remember
> > what the defaults might have been. However, having a bad structure
> > definition can cause all sorts of memory corruption so it is worth ruling
> > out.
> >
>
More information about the cmucl-help
mailing list