topic Re: macro never comes back in Operating System - OpenVMS

macro never comes back

IT Response — Thu, 23 Jul 2009 15:52:20 GMT

.title loop

.entry loop, ^m<>
10$: brb 10$

.end loop
$ macro /noopt /debug loop
$ link /debug loop
$ run loop

OpenVMS Alpha Debug64 Version V8.3-014

%DEBUG-I-INITIAL, Language: AMACRO, Module: LOOP

DBG> step
stepped to LOOP\$L1
4: 10$: brb 10$
DBG> step <<<<< never comes back until I hit ^Y
Interrupt

Code never comes back until a ^Y is hit. There is clearly a problem with DBG. Why does it hang?

Re: macro never comes back

Hoff — Thu, 23 Jul 2009 16:23:46 GMT

So to distill this problem report down to its core, you're reporting that the OpenVMS Alpha V8.3 debugger can't single-step past a Macro32 branch to self instruction; past a one-instruction infinite loop.

Ok. Interesting. Nice reproducer. Can't say I'd expect to see that construction in production code, but...

Call HP, and report the bug formally.

Re: macro never comes back

Robert Gezelter — Thu, 23 Jul 2009 16:34:56 GMT

IT Response,

I concur with Hoff, it would appear to be a bug.

Before reporting it, I would suggest that you try the other obvious one line loops (e.g., those involving the BRW and JMP instructions).

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

Re: macro never comes back

John Gillings — Fri, 24 Jul 2009 04:42:17 GMT

I don't concur with Hoff and Robert.

This is NOT a bug or a problem with DEBUG.

This is correct behaviour! DEBUG is doing precisely what you asked.

The default for STEP is STEP/LINE. It's supposed to execute until you reach the next line of code. Since your program never reaches the next line (because there isn't one), it doesn't break. QED.

You can always hit ^Y and type DEBUG to return to the DBG prompt. That's the correct, documented way to break out of a loop.

Alternatively, to debug this construct (if that makes sense!) you can use STEP/INSTRUCTION which will break after each executed instruction.

DBG> step/inst
stepped to LOOP\LOOP\%LINE 3+1: mov r42 = r12
3: .entry loop, ^m<>
DBG> step/inst
stepped to LOOP\LOOP\%LINE 3+2: mov r29 = r12 ;;
3: .entry loop, ^m<>
DBG> step/inst
stepped to LOOP\LOOP\%LINE 4: br.many 0000000
4: 10$: brb 10$
DBG> step/inst
stepped to LOOP\LOOP\%LINE 4: br.many 0000000
4: 10$: brb 10$
DBG> step/inst
stepped to LOOP\LOOP\%LINE 4: br.many 0000000
4: 10$: brb 10$
DBG> step/inst
stepped to LOOP\LOOP\%LINE 4: br.many 0000000
4: 10$: brb 10$
DBG> step/inst
stepped to LOOP\LOOP\%LINE 4: br.many 0000000
4: 10$: brb 10$
DBG> step/inst
stepped to LOOP\LOOP\%LINE 4: br.many 0000000
4: 10$: brb 10$

Re: macro never comes back

Robert Gezelter — Fri, 24 Jul 2009 10:38:13 GMT

John,

Mea culpa.

Indeed, the HELP text under /LINE notes that it is the default.

In fact, I was burned often enough long ago that my hand no longer will type STEP when I am sitting at a subroutine call or branch, I
automatically type STEP/INTO.

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

Re: macro never comes back

Hoff — Fri, 24 Jul 2009 10:47:55 GMT

It's one of those wonderful hair-splits, and here I think the current behavior for this, um, degenerate case is wrong. At its core, this is the difference between the next line of source code (which is 10$: brb 10$), and a different line of source code. What I think is happening here is that the debugger is itself getting stuck in the infinite loop; that there's a boundary case here. But if you're going to step through an infinite loop in the interim and prior to HP making a statement on this behavior, well, stick a NOP into the loop while you're confirming that the infinite loop here is, in fact, infinite, and that should coax the debugger into allowing you to prove the loop is infinite.

Re: macro never comes back

Robert Gezelter — Fri, 24 Jul 2009 12:29:06 GMT

Gentlemen,

For the record, I verified that this behavior also occurs on VAX.

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

Re: macro never comes back

John Reagan — Mon, 27 Jul 2009 17:58:55 GMT

So think about what happens when you ask the debugger to step to the next line.

For code without branches, the debugger will scan forward looking for PCs that map to a different line number than the current PC. It will set a break point there; begin execution of the code; take the breakpoint; put back the original instruction; print the DBG prompt.

Of course the complicated case is when the line contains a branch. For some computed branch where you don't know the target or is some conditional branch, I think the debugger sets a breakpoint on the branch itself, begins execution; takes the breakpoint; puts back the branch; does a single step; and checks if we're at a different line or not. Repeat as necessary.

When the debugger does know the target [ie, this exact situation], the debugger checks the destination and if the PC/line mapping is a DIFFERENT line, it will set a breakpoint. In this case, the destination is the same line and it wouldn't surprise me that the breakpoint is not set.

You can certainly ask HP to check with the debugger team on the philosophy of such a STEP, but it didn't surprise me that it loops.

Also remember that some languages aren't "single line". Consider the double-nested infinite loop [which takes O(n2) time to complete. :)]

1: 2: goto 2; goto 1;

where's the next LINE?