... just another bit. In order to have that output I put .set noreorder in the call_to_lisp definition. ASM performs a reorder of statements, and with that command we force to follow the statements as thet are written.
regards, Fausto 2014-09-09 0:02 GMT+02:00 Fausto Saporito <[email protected]>: > 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
