Re: CMUCL 18c building on tru64 5.1

On Thu, Sep 4, 2014 at 9:34 AM, Fausto Saporito <[email protected]>
wrote:

> 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.
>

​You mean assembler? But maybe the assembler is doing some optimization
too.​


>
> Is it possible substitute this call_into_lisp with some C function ?
>

​Probably not. Unless you count lots of inline assembly in a C function as
a C function.​


>
> regards,
> Fausto
>
>
> 2014-09-04 18:17 GMT+02:00 Raymond Toy <[email protected]>:
> >
> >
> >
> > On Thu, Sep 4, 2014 at 3:46 AM, Fausto Saporito <
> [email protected]>
> > 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 <[email protected]>:
> >> > 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.
> >> >
> >
> >
>
_______________________________________________
cmucl-help mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-help