[cmucl-help] CMUCL 18c building on tru64 5.1
Fausto Saporito
fausto.saporito at gmail.com
Thu Sep 4 16:34:52 UTC 2014
Hello Ray,
maybe these are some optimization done by the compiler.
You gave me an idea... I'll try to disable all optimizations, and do
again the debug.
Is it possible substitute this call_into_lisp with some C function ?
regards,
Fausto
2014-09-04 18:17 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
>
>
>
> 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