[cmucl-help] 19c alpha [Was Re: CMUCL 18c building on tru64 5.1]

[Raymond Toy]

>From the ldb prompt, you can enter "back" to get a backtrace. This might
provide some hints on what to look for.


On Tue, Sep 9, 2014 at 4:55 PM, Fausto Saporito <fausto.saporito at gmail.com>
wrote:

> ok... now "the party is over" :-)
>
> In initial-function, and running.
> GLOBALDB-INIT
> FDEFN-INIT
> TYPEDEF-INIT
> CLASS-INIT
> TYPE-INIT
> Calling top-level forms.
> %primitive halt called; the party is over.
> LDB monitor
> ldb>
>
> what's happening ?
>
> 2014-09-10 1:43 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
> > Try this. In your cross script, somewhere after new-backend, add the
> > following:
> >
> > (clrhash kernel::*modular-funs*)
> >
> > Oh, and if you're using bin/load-world.sh, be sure to use the -p option
> so
> > pcl isn't loaded. (Or just use the CONTINUE restart to skip loading of
> pcl.)
> >
> > On Tue, Sep 9, 2014 at 3:55 PM, Fausto Saporito <
> fausto.saporito at gmail.com>
> > wrote:
> >>
> >> I did such change... but I have always the same error...
> >> I checked in the source code and that function should be included only
> >> with modular-arith!
> >>
> >> ;; Not sure this is 100% right, but the defoptimizer for ash only
> >> ;; calls ash-left-mod32 when the COUNT is known to be a (UNSIGNED-BYTE
> >> ;; 5), which is what %ASHL wants.
> >> #+modular-arith
> >> (defun vm::ash-left-mod32 (integer count)
> >>   (declare (type integer integer)
> >>            (type (integer 0 31) count))
> >>   (bignum::%ashl (ldb (byte 32 0) integer) count))
> >>
> >> if I understood well the #-syntax.
> >>
> >> Maybe, the cross compiler override such definition... I don't know...
> >>
> >>
> >> 2014-09-10 0:22 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
> >> >
> >> >
> >> > On Tue, Sep 9, 2014 at 3:14 PM, Fausto Saporito
> >> > <fausto.saporito at gmail.com>
> >> > wrote:
> >> >>
> >> >> ok... this is interesting:
> >> >>
> >> >> ldb> print $1
> >> >> $1=       0x30182847: other pointer
> >> >>             header: 0x000003ba: fdefn
> >> >> $2=         name: 0x30182817: ASH-LEFT-MOD32
> >> >> $nil=       function: 0x2800000b: NIL
> >> >>             raw_addr: 0x00010140: 16464
> >> >>
> >> >> I remember ASH-LEFT-MOD32... is something related to
> modular-arithmetic
> >> >> ?
> >> >> I disabled such feature, but I'm not sure if this could be related.
> >> >
> >> >
> >> > Yes, that's modular arithmetic.  Something is leaking.
> >> > Maybe in your cross script, add something like
> >> >
> >> > (setf *features* (remove :modular-arith *features*))
> >> >
> >> > after c::new-backend. It might be good to do that with :double-double
> >> > and
> >> > :linkage-table. Not sure though, but probably harmless if you do since
> >> > alpha
> >> > doesn't support that.
> >> >
> >> >>
> >> >>
> >> >>
> >> >> 2014-09-10 0:04 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
> >> >> >
> >> >> >
> >> >> > On Tue, Sep 9, 2014 at 3:00 PM, Fausto Saporito
> >> >> > <fausto.saporito at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Now lisp is more verbose:
> >> >> >>
> >> >> >> axpvm01.gitanes.taz> ./lisp -core kernel.core
> >> >> >> In initial-function, and running.
> >> >> >> GLOBALDB-INIT
> >> >> >> FDEFN-INIT
> >> >> >> Error: Undefined symbol.
> >> >> >>     SC: 16, Offset: 23  $1=       0x30182847: other pointer
> >> >> >> LDB monitor
> >> >> >> ldb>
> >> >> >>
> >> >> >> in lisp.map there's no address 30182847
> >> >> >
> >> >> >
> >> >> > Because you're somewhere in Lisp code.
> >> >> >
> >> >> > Type "help" to get some help on how to use ldb.  At this point, you
> >> >> > can
> >> >> > probably learn a lot by doing
> >> >> >
> >> >> > print $1 (or print 0x30182847)
> >> >> >
> >> >> > This should tell you at least the symbol name. And since it's
> >> >> > undefined,
> >> >> > we'll have to figure out why it's undefined.  Could be an issue in
> >> >> > the
> >> >> > 19c
> >> >> > source code, or perhaps something bad happening with
> cross-compiling
> >> >> > from
> >> >> > 19c linux with :linkage-table enabled.
> >> >> >
> >> >> > But this progress is really encouraging!
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> I'lll try to understand which is the missing function.
> >> >> >>
> >> >> >>
> >> >> >> 2014-09-09 23:47 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
> >> >> >> >
> >> >> >> >
> >> >> >> > On Tue, Sep 9, 2014 at 2:07 PM, Fausto Saporito
> >> >> >> > <fausto.saporito at gmail.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> Hello all,
> >> >> >> >>
> >> >> >> >> so we have targeted the right process :-) I got always a
> >> >> >> >> sigsegv...
> >> >> >> >> but it's different....
> >> >> >> >> debug_print is working... is there a way to have those messages
> >> >> >> >> printed on the screen ? At the moment I can see them only in
> dbx
> >> >> >> >> :)
> >> >> >> >
> >> >> >> >
> >> >> >> > They should be showing up on the screen. debug_print just does
> >> >> >> > printf/fflush, so they should be there.
> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Yes... I have to go back to rebuild kernel.core after generated
> >> >> >> >> lisp.nm, but it seems not all the functions are present in
> >> >> >> >> lisp.nm
> >> >> >> >> The most obvious are missing! Like sin, cos, tan, killpg, etc
> ...
> >> >> >> >> and
> >> >> >> >> they are defined in undefineds.h
> >> >> >> >
> >> >> >> >
> >> >> >> > Some of these should be defined since they're used in
> kernel.core.
> >> >> >> > FWIW,
> >> >> >> > killpg is not in lisp.nm on my linux build (normal compile).
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Ray
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Ray
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Ray
> >
> >
> >
> >
> > --
> > Ray
>



-- 
Ray