Debugger on Alpha VMS 7.3-2

[Patrick R Benson]

Hi, am still getting used to developing on an Alpha, rather than a VAX.
A single difference with the debugger is very annoying- when stepping thru the code, STEP/INTO doesnt work immediately- one seems to have to hit STEP/INTO as many times as there are parameters on the subroutine/function , before entry.
Cant find if possible to change this behaviour in the manual.
(dont always want to SET BREAK)

[Ian Miller.]

Is the code optimised and in what language is it written?

It sounds like you are stepping through some code that processes the parameters.

[Robert Gezelter]

Patrick,

I too have never experienced what you describe. Can you be more specific?

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel]

What language?

On alpha, for basic debugging, you really need to compile /NOOPT/DEBUG. Did you?

This is because the compilers intermingle instructions from various source lines for optimal execution, so when you step it may be working on several lines at a time.

Alpha may also have inlined the subroutines more aggresively than on VAX.

And you are using STEP/LINE, not STEP /INST?

On VAX, in MAcro and often in other languages, a single source line may well correspond to a single instruction. On Alpha that is almost never the case. There are always may little instruction steps.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Patrick R Benson]

Code is FORTRAN, not optimised- as its in debug.

Building a demo has made me realise that its an artifact of debugger and continuation lines-
i.e.
call testfun (cdum, idum1, idum2, idum3)
doesnt do it , whereas
call testfun (cdum,
+ idum1,
+ idum2,
+ idum3)
does.

this may look trivial, in the demo ( I should just put all the parameters on one line) but when indented for IFs 5 or 6 times, and with variable names 10 or 12 chars long, the call ends up on RHS and continuations are needed.

when the subroutine has 10 or 12 params, and the call is inside a loop
the keypad really smokes! (and so do I)

$ for/noopt/den test_prog
$ link/deb test_prog
$ r test_prog
DBG> Set Mode Screen; Set Step Nosource
DBG> step
DBG> step
DBG> step/into to the call
DBG> step/into 2nd param
DBG> step/into 3rd param
DBG> step/into back to call
DBG> step/into finally into the routine
.....

$ ty test_prog.for
program test_prog
implicit none
character*20 cdum
integer idum1,idum2,idum3
cdum = 'test_fun entered'
call testfun (cdum,
+ idum1,
+ idum2,
+ idum3)
stop
end
subroutine testfun (c,i1,i2,i3)
character*(*) c
integer i1, i2, i3
write (6,*) c
return
end

[Hoff]

What language?

Post up a source example of a function call, and we'll have a look.

Are you evaluating functions within the argument list?

I've seen similar behaviors with cross-image activations, and with argument lists that evaluate functions, and (as others have mentioned here) with optimized code.

There are also cases where functions are in-lined, which -- if you're debugging optimized code -- can look rather weird. (I generally ask and suggest and help the compiler to inline, as the resulting code is faster.)

There's some code you can experiment with here: http://h71000.www7.hp.com/wizard/wiz_2486.html

And do you have any debugger ECO kits or special debuggers loaded? Other ECOs?

Stephen Hoffman
HoffmanLabs LLC

[Patrick R Benson]

Please let me do that again with the 'retain format' button on, so that cut/pasted code will compile-

Code is FORTRAN, not optimised- as in debug.

Building demo has made me realise that its an artifact of debugger
and continuation lines-

i.e.
call testfun(cdum,idum1,idum2,idum3)
doesnt do it , whereas
call testfun (cdum,
+ idum1,
+ idum2,
+ idum3)
does.

this may look trivial in the demo ( I should just put all the parameters on one line)
but when indented for IFs 5 or 6 times, and with variable names
10 or 12 chars long, the call is forced to RHS and continuations are necessary.

When the subroutine has 10 or 12 params, and the call is inside a loop
the keypad really smokes!

$ for/noopt/deb test_prog
$ link/deb test_prog
$ r test_prog
DBG> Set Mode Screen; Set Step Nosource
DBG> step
DBG> step
DBG> step/into to the call
DBG> step/into 2nd param
DBG> step/into 3rd param
DBG> step/into back to call
DBG> step/into finally into the routine
.....

$ ty test_prog.for
program test_prog
implicit none
character*20 cdum
integer idum1,idum2,idum3
cdum = 'test_fun entered'
call testfun (cdum,
+ idum1,
+ idum2,
+ idum3)
stop
end
subroutine testfun (c,i1,i2,i3)
character*(*) c
integer i1, i2, i3
write (6,*) c
return
end

[John Gillings]

Patrick,

Unfortunately we have all been spolied by VAX architecture. It's a dream to debug, regardless of optimization. VAX assembler is easy to follow and most language constructs fall into a fairly obvious assembler sequence. There are also the "huge" instructions like CALL[x] and RET which do very complex things in a single hit.

On Alpha, there's really no such thing as /NOOPTIMIZE. If you were to compile most source code directly into sequential Alpha instructions performance would be terrible! /NOOPT really means "use as little optimization as possible, with half way decent performance". This means if you examine a particular block of assembly code, you'll find adjacent instructions still belong to different (and possibly widely separated) lines of code. DEBUG then has a dilemma. Either you religiously tag every instruction to a line of code, and bounce all over the place as STEP commands are executed, or you fudge things and gloss over some instructions, pretenting they belong to a different instruction.

For routine calls, instead of a single VAX instruction, the compiler must generate a potentially complex sequence to setup actual arguments. Since this is a very common source of programming errors, you need to be able to single step through them.

You may be able to achieve what you want with:

DBG> STEP/CALL
DBG> STEP/INTO

If you think the move from VAX to Alpha is hard for debuuging, wait until you see Integrity (where /NOOPT is all but impossible!).

[Patrick R Benson]

Thanks to all who contributed.

I am closing it because its clear that the solution I wanted isnt going to be possible, due to the difference in architecture-
It seems to me that it should be simple to add some code to the debugger which says-'continuations in a call statement can be ignored when processing FORTRAN,and don't need a STEP to themselves'.
but of course it would cost money - and for a language of decreasing popularity. I am grateful that most other things have converted so well.