Conference turris::debug

1848.0. "About steps: DOC says ... debugger makes !?" by BACHUS::SABLON (Mich�le Sablon, TP/IM Support Belgium 856-7238) Thu Mar 13 1997 11:42

BASIC V1.2
AXP VMS V6.2 + ALPDEBU06
AXP VMS V7.1

    BASIC documentation states that (cf Release Notes � 7.2.3)

	     _____________________________________________________________
                                     DEC BASIC               VAX BASIC
             Action__________________Results_________________Results______

             STEP/INTO DEF func-     Steps into function     Steps into
             tion                                            function
	     ...
             STEP/INTO GOSUB         Steps into RTL          Steps into
             block                                           RTL
             _____________________________________________________________


    It doesn't says a lot about STEP/OVER. But one would expect to execute the 
    instruction and move to the next one.

    The little program below uses DEF functions and a GOSUB subroutine. It shows 
    it doesn't behave as expected:

    1. STEP/INTO DEF function steps in fact into RTL
    2. STEP/OVER GOSUB goes to the first instruction of the the subroutine. (I 
       found a problem description of this in DECWIN_95 via COMETS)

    Documentation, debugger or BASIC problem ?
    Best,
    Mich�le.

==========

PROGRAM test
    
    !+
    ! MAP Declarations
    !-
    MAP	    (werk) WORD length, STRING a$ = 5

    DEF fn.wt% ( f.y$, f.x$, f.t$ )
	PRINT esc + "[" + f.y$ + ";" + f.x$ + "H", f.t$
    END DEF
    DEF fn.pc% ( f.y$, f.x$ )
	PRINT esc + "[" + f.y$ + ";" + f.x$ + "H";
    END DEF 

    SET NO PROMPT

    GOSUB clearSub
    p%	    = fn.wt%( "10","5","Geef 5 posities in : _____" )
    p%	    = fn.pc%( "10","26")
    LINPUT  a$
    PRINT   "Enter value is '"; a$; "'	of length "; LEN (a$)
    PRINT   "and bell: ", BEL
    CALL    LIB$WAIT(30.0)
    INPUT   b$
    PRINT   "if ^X worked, the input string '"; b$; "'	is of 0 length;";    &
	    "len = "; LEN (b$)
    STOP

    clearSub:
	PRINT esc + "[2J"
    RETURN

END PROGRAM 1

$ basic/noopt/debug x
$ link/debug x
$ r/deb x

         OpenVMS Alpha DEBUG Version V7.1-000

%DEBUG-I-INITIAL, Language: BASIC, Module: PAUWELS_TEST

DBG> sho step
step type: source, nosilent, by line,
           over routine calls
DBG> Step
stepped to PAUWELS_TEST\%LINE 18
    18:     SET NO PROMPT
DBG> Step
stepped to PAUWELS_TEST\%LINE 20
    20:     GOSUB clearSub
DBG> Step
stepped to PAUWELS_TEST\CLEARSUB
    33:         PRINT esc + "[2J"
DBG> Step
stepped to PAUWELS_TEST\%LINE 34
    34:     RETURN
DBG> Step
stepped to PAUWELS_TEST\%LINE 21
    21:     p%      = fn.wt%( "10","5","Geef 5 posities in : _____" )
DBG> Step
stepped to PAUWELS_TEST\%LINE 22
    22:     p%      = fn.pc%( "10","26")
DBG> set step into
DBG> Step
%DEBUG-I-SOURCESCOPE, Source lines not available for .0\%PC
        Displaying source in a caller of the current routine
stepped to SHARE$LIBRTL_CODE0+618288
%DEBUG-I-SOURCESCOPE, Source lines not available for .0\%PC
... 

Interesting...the debugger makes no attempt to distinguish between calls to
RTLs and user written functions.  EXCEPT that, recently, the compiler back
end, GEM, does mark some JSRs that it inserts as "only interesting if
stepping by instruction"...usually calls to LIB$OTS functions that can almost
be thought of as atomic operations.  If so marked, V7.0 and later debuggers,
will step over these JSRs when not stepping by instructions even when stepping
/INTO.

Looking at the machine code for the line in your example (for my compile and
link, it is line 19), I see 3 calls, 2 JSRs and 1 BSR.  The JSRs are calls
to LIBRTL routines...not sure which ones but I'd guess that they are setting
up the string input parameters.  The BSR is to your fn.pc%.  The JSRs are NOT
marked as "only interesting if stepping by instruction"...so the debugger steps
into them.  This is expected behavior...though obviously not ideal.

Lon