From: SMTP%"VAXman@tmesis.com" 18-MAR-1997 10:34:37.14 To: PINKLEY@EISNER.DECUS.ORG, NICK.DESMITH@AXL-UK.COM, EVERHART@star.zko.dec.com, EVERHART@ARISIA.GCE.COM, LOCKS@SVHDEV.BT.CO.UK CC: Subj: SNAPSHOT ASSumption :( FYI, So far, I have 3 people that have SNAPSHOT: Steve Lock Jon Pinkley Glenn Everhart Of course, Nick de Smith is in the loop on this, he just can get a copy because of passive FTP filewall issues. -- Jon reported a few issues to me and I look into them just this AM. I apologise, it was my assumptions that caused the problem. Jon's been testing all of my software on OpenVMS V6.2. While I built the product for OpenVMS V6.2, it was done on my Alpha running OpenVMS E7.1 (Yes, I have V7.1, I just don't have time). I made an assumption about the layout of the stack during the delivery of the AST. The AST is a user mode AST defined with a .ENTRY and a register save mack. Therefore, the procedure descriptor will not be a null frame procedure descriptor. The procedure descripotr could be either one of a heavyweigh stack-frame procedure descriptor or a register frame proceudre descriptor. One, I have never seen the AMACRO32 compiler produce a register frame descriptor and two, the AST has out-bound calls therefore, making the heavyweight stack frame procedure des- criptor the logical choice. Ok. So, the AST procedure is invoked. After the prologue code has been exercised, the frame is made current by cpying the SP to the FP. According to the calling standard, upon entry, register R27 is the linkage pointer for the procedure and, by convention, is the address of the procedure descriptor. This is saved by the pro- logue in the first quadword of the stack frame. With me so far? On the stack at the time the AST is delivered is the following: +--------+:AST stack frame | PDSC | = = |R2-R15, | | R29 | +--------+:SCH$ASTDEL stack Frame | | +--------+:ASTSTK stack Frame | | |F0,F1,- | | F10-F30| | | |R0,R1,- | | R16-R29| +--------+:INTSTK stack frame | R2-R7 | | PC | | PS | +--------+:SP at time of AST delivery My AST needs to locate the above four stack contribution frame in order gether the information needed to feign a mechanism array. My AST code did the following: MOVL SP,R0 ; save current stack location MOVL (R0),R1 ; get AST's procedure descriptor MOVAB @PDSC$L_SIZE(R1)[R0],R0 ; move past AST stack contribution This was my mistake! I made an assumption that by simply adding the size of the stack frame of the AST to the stack frame base would place me at the stack frame of the SCH$ASTDEL routine. WRONG! To properly find this address, I need to recover its frame pointer (saved in the AST stack frame by the prologue) from the stack frame. Thankfully, the calling standard makes the rather rigid. The FP (R29) is saved in the last quadword of the procedure's stack frame. I added the following to the above three instructions to correct my assumption: EVAX_LDQ R0,-QUAD(R0) ; get stack frame address of ASTDEL Without this, the computation of the ASTSTK and the INTSTK frames will or can be skewed. Jon also asked: >What is the SNAPSHOT$AST_LEI.EXE for? It is not loaded by the >install_snapshot.com file. (Oh... I just did another ANAL/sys show exec >and it is there now, so it must get demand loaded.) Jon is right. I detoured from my typical procedure of loading the execlet in the installation or product startup. The execlet is small enough that it can be quickly loaded by the first user to exercise the SNAPSHOT com- mand. The code simply calls LDR$LOAD_IMAGE in a $CMEXEC call. If the execlet has been loaded, this returns a SYSTEM-F-DUPLNAM which is ignored. All other errors are, of course, returned. I then jump to kernel mode an call LDR$REF_INFO to obtain the execlet image handle. Once I have this, I can find the AST routine and/or AST procedure descriptor (if on Alpha) using the same technique I employed in SYMBOL; that is, the execlet's initialization routine loads the AST procedure address (alpha) or entry point(VAX) at a known locale in the loaded execlet (ie, the first quadword of the writeable resident por- tion of the execlet. Then come the simple stuff of allocating a tiny bit of nonpaged pool, fill in the pool to make it look like an ACB and invoke SCH$QAST. I do a few more checks than in the original PDUMP. One, I check to see if the target _has_ P0 space before subjecting it to the user mode AST. Without this, if delivered to a process sitting at the DCL prompt, DCL would cough up a stack dump when the next image was activated. For fun, put on your thinking caps and tell me why! :) Jon also asked: >I thought that it claimed to leave the target process basically unscathed, >(which it does claim, however I have no VAX to verify this on). I willnow. If trashed his program because the assumption about the stack most likely caused an ACCVIO, dumping his process. >(These are wild ass guesses... I don't have any alpha crash dump experience). > >It appears to be a LDL R24,#X0010(R1) > >SNAPSHOT$AST_LEI+02158: LDA R25,#X002B(R31) >SNAPSHOT$AST_LEI+0215C: STL R25,#X0060(SP) >SNAPSHOT$AST_LEI+02160: LDL R1,(R0) >SNAPSHOT$AST_LEI+02164: BIS R31,R1,R1 >SNAPSHOT$AST_LEI+02168: LDL R24,#X0010(R1) ; <-- >SNAPSHOT$AST_LEI+0216C: ADDL R0,R24,R0 >SNAPSHOT$AST_LEI+02170: STL R0,(SP) >SNAPSHOT$AST_LEI+02174: LDL R23,(R0) >SNAPSHOT$AST_LEI+02178: BLBS R23,#X00005E Jon supplied the following from his system. For the sake of those with minimal stack tracing experience on the Alpha, the LDL was attempting to obtain the PDSC$L_SIZE from the "supposed" SCH$ASTDEL stack frame. PDSC$L_SIZE = 16(10) or 10(16). R0, in the LDL just above it, should be the address of the SCH$ASTDEL stack frame. LDL R1,(R0) is attempting to obtain the address of the PDSC of SCH$ASTDEL from the stack. No guessing what it may have loaded from (R0)... I am rebuilding SNAPSHOT now and, this time, I'll reboot the Alpha into V6.2 and test it. I'll then send all of you a message when you can pick it up. BTW, it seems to be ok on V7.1. I suspect this is due to a small change in the AST delivery code for threading an some filler alignment. VAXman- VAXman@TMESIS.COM ================== RFC 822 Headers ================== Return-Path: system@tmesis.com Received: by dimond.zko.dec.com (UCX V4.1-12A, OpenVMS V6.2 VAX); Tue, 18 Mar 1997 10:34:32 -0500 Received: from ALPHA.TMESIS.COM by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA29669; Tue, 18 Mar 1997 10:22:19 -0500 (EST) Received: by TMESIS.COM (MX V4.1 AXP) id 1; Tue, 18 Mar 1997 10:18:48 EST Date: Tue, 18 Mar 1997 10:18:47 EST From: "Brian Schenkenberger, VAXman-" Reply-To: VAXman@TMESIS.COM To: PINKLEY@EISNER.DECUS.ORG, NICK.DESMITH@AXL-UK.COM, EVERHART@star.zko.dec.com, EVERHART@ARISIA.GCE.COM, LOCKS@SVHDEV.BT.CO.UK Message-ID: <009B170E.3B033B25.1@TMESIS.COM> Subject: SNAPSHOT ASSumption :(