From: SMTP%"MACRO32%WKUVX1.BITNET@uu7.psi.com" 7-JUL-1993 11:59:49.27 To: EVERHART CC: Subj: Re: Clarification on Debugger Question X-Listname: "VMS Internals, MACRO, & BLISS Discussions" Warnings-To: <> Errors-To: MacroMan%WKUVX1.BITNET@uu7.psi.com Sender: MacroMan%WKUVX1.BITNET@uu7.psi.com From: X-Newsgroups: vmsnet.internals Subject: Re: Clarification on Debugger Question Date: 7 Jul 1993 15:01:35 GMT Organization: Digital Equipment Corporation Lines: 65 Distribution: world Message-Id: <21eogf$9cl@usenet.pa.dec.com> Reply-To: MACRO32%WKUVX1.BITNET@uu7.psi.com Nntp-Posting-Host: gauche.zko.dec.com X-Newsreader: mxrn 6.18-5 To: MACRO32@WKUVX1.BITNET X-Gateway-Source-Info: USENET In article , mcdermott@draper.com (Christopher K. McDermott) writes: |>I have found a work around for the problem (see original article) I |>was having, as illustrated below, but, I would still like to know |>extactly what the *debugger* is doing with the space above the top of |>the stack. Again, if anyone has a clue about what it is doing, or how |>to stop it (like tell the debugger that this a MACRO routine, and I'll |>be mucking with the SP), please let me know. And then in article <1993Jun25.000118.1@condor>, blacka@logica.co.uk (Andrew Black) replies: |>My understanding of how the debugger works is as follows. When you set |>a breakpoint, it plants a BPT instruction in the code. When reached, |>it casuse the CPU to take an exception, which in turn places signal |>and mechanism arrays on the stack. This then filters through into |>DEBUG. Likewise, single stepping casues an exception to be taken for |>every instruction. thus the area of stack that is logically above SP |>(arithmetically below sp) is likely to be fairly heavily visited by |>debug, by any other conditions that your program may invoke, by |>ASTs... |> |>( I don't vouch for the details of how debug works, but I am pretty |>sure of the general idea) I would have answered this sooner, but I've been on vacation. The explanation given by Andrew is on the mark. DEBUG does make use of the user mode stack. When an exception is delivered, not only are signal and mechanism arrays pushed (by the VMS exception delivery mechanism), but debug's exception handler is called, so it's using stack space, too. Debug's exception handler invokes other routines as well. There is no way to change or stop this behavior. The original problem Chris was having with his thread context switcher has been solved, but I'd still like to give this warning: homegrown thread context switchers must take extreme care when writing into FP and SP. Don't violate the rules/assumptions in both the Alpha (or VAX) Architecture Reference Manual and the OpenVMS Calling Standard Manual or you will have no end of troubles. Two important rules I can think of: 1. SP must always point to valid memory, otherwise exception delivery (e.g., debugging) will fail. 2. SP is always equal to or less than FP. In other words, SP>FP is illegal. This implies that FP and SP have to be updated *very* carefully. The prefered way to handle this is to not handle it at all, but to use CMA and let it worry about the details. Not only that, but the debugger has special capabilities for debugging CMA threads which isn't available to homegrown thread managers. Your own business needs will determine whether or not it makes sense to replace a homegrown thread package with CMA, and I can understand that for some it makes sense to try and stick with the homegrown package. This warning is intended primarily for those who need thread capabilities and are thinking of writing a thread manager. You don't know what you're getting into, and it's best if you keep it that way. :-) Hope this helps. -Jeff E. Nelson -OpenVMS DEBUG Architect -Digital Equipment Corporation -Internet: jnelson@gauche.zko.dec.com -Not an official statement of Digital Equipment Corporation