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 <[email protected]>: > On Mon, Sep 8, 2014 at 10:41 AM, Fausto Saporito <[email protected]> > 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 <[email protected]>: >> > ok, Ray. >> > I'll use 19c from now on. >> > >> > thanks, >> > Fausto >> > >> > >> > 2014-09-08 18:24 GMT+02:00 Raymond Toy <[email protected]>: >> >> >> >> >> >> >> >> On Sun, Sep 7, 2014 at 9:42 PM, Fausto Saporito < >> [email protected]> >> >> 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 < >> [email protected]> >> >>> ha scritto: >> >>> >> >>> >> >>> >> >>> >> >>> On Sun, Sep 7, 2014 at 9:25 AM, Fausto Saporito >> >>> <[email protected]> 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 <[email protected]>: >> >>>> > 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 >> >>>> > <[email protected]> >> >>>> > 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 >> >>>> >> <[email protected]>: >> >>>> >> > It's INITIAL-FUNCTION: >> >>>> >> > >> >>>> >> > 0x3028EEE8: %INITIAL-FUNCTION #x3028EED1 >> >>>> >> > >> >>>> >> > so it seems ok... >> >>>> >> > >> >>>> >> > >> >>>> >> > 2014-09-04 22:29 GMT+02:00 Carl Shapiro <[email protected] >> >: >> >>>> >> >> On Thu, Sep 4, 2014 at 9:17 AM, Raymond Toy < >> [email protected]> >> >>>> >> >> 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 > [email protected] > http://lists.zs64.net/mailman/listinfo/cmucl-help _______________________________________________ cmucl-help mailing list [email protected] http://lists.zs64.net/mailman/listinfo/cmucl-help
