| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1829.1 | OpenVMS DEBUG VAX V7.0 steps over line | CSC32::D_SANFORD | | Thu Jan 30 1997 16:04 | 108 |
| OpenVMS VAX DEBUG Version V7.0-000
DEC Pascal V5.4-41, V5.5-57
OpenVMS VAX V7.0
RE: .0 tested using latest Pascal release V5.5, same problem. The
below is also related (I think):
When stepping with the debugger will not step correctly, esentially it
will step over two lines with a single step. For example:
$ PASCAL/NOOPT/DEBUG test
$ LINK/DEBUG test
$ RUN test
OpenVMS VAX DEBUG Version V7.0-000
%DEBUG-I-INITIAL, Language: PASCAL, Module: DIGITAL
DBG> s/into
stepped to DIGITAL\A\%LINE 26
26: for x := 1 to 10 do
DBG> s
stepped to DIGITAL\A\%LINE 28
28: one_line := integer_to_text(x,1) + 'A';
DBG> s
In routine all_for_one
stepped to DIGITAL\A\%LINE 30
30: all_for_one;
DBG> s
In routine all_for_one
stepped to DIGITAL\A\%LINE 31
31: all_for_one;
DBG> s
In routine all_for_one
stepped to DIGITAL\A\%LINE 32
32: one_line := integer_to_text(x,1) + 'A';
DBG> s
In routine all_for_one
stepped to DIGITAL\A\%LINE 34
34: all_for_one;
DBG> s
In routine all_for_one
stepped to DIGITAL\A\%LINE 35
35: all_for_one;
DBG> s
In routine all_for_one
stepped to DIGITAL\A\%LINE 26+3
26: for x := 1 to 10 do
DBG> exit
Line 29: and Line 33: were executed (In routine all_for_one), but
the debugger did not stop on these.
The problem will not happen if you remove the following line:
one_line := integer_to_text(x,1) + 'A';
The debugger is confused and somehow thinks Line 28/29 are one line.
Regards, Drew Sanford
Customer Support Center
RE: C970128-3670
Example to duplicate problem:
program digital(input,output);
type
string = varying [255] of char;
FUNCTION Integer_to_Text (Arg: INTEGER; LEN:INTEGER := 6): String;
VAR
Text_value: STRING;
BEGIN
WRITEV(Text_value, Arg:LEN);
Integer_to_Text := Text_value;
END;
procedure all_for_one;
begin
writeln('In routine all_for_one');
end;
procedure A;
var
x : integer := 1;
one_line : string := '';
begin
for x := 1 to 10 do
begin
one_line := integer_to_text(x,1) + 'A';
all_for_one;
all_for_one;
all_for_one;
one_line := integer_to_text(x,1) + 'A';
all_for_one;
all_for_one;
all_for_one;
end;
end;
begin
A;
end.
|
| 1829.2 | OpenVMS VAX DEBUG V7.0 %SYSTEM-F-RADRMOD | CSC32::D_SANFORD | | Thu Jan 30 1997 16:12 | 164 |
| OpenVMS VAX DEBUG Version V7.0-000
DEC Pascal V5.4-41, V5.5-57
OpenVMS VAX V7.0
RE: .0 I think this is just another variation of the original problem.
When stepping with the debugger the application will fail with:
%SYSTEM-F-RADRMOD, reserved addressing fault at PC=000002B3, PSL=03C00004
break on unhandled exception at DIGITAL\E\%LINE 10
If you do not step (GO) or use OpenVMS Alpha or OpenVMS VAX V6.2 or
earlier this does not fail.
$ PASCAL/NOOPT/DEBUG test
$ LINK/DEBUG test
$ RUN test
OpenVMS VAX DEBUG Version V7.0-000
%DEBUG-I-INITIAL, Language: PASCAL, Module: DIGITAL
%DEBUG-I-NOTATMAIN, Type GO to reach MAIN program
DBG> g
break at routine DIGITAL
107: A;
DBG> s/into
stepped to DIGITAL\A\%LINE 96
96: b(one_line);
DBG> s
stepped to DIGITAL\A\%LINE 97
97: for x := 1 to 10 do
DBG> s
stepped to DIGITAL\A\%LINE 99
99: writeln(one_line);
DBG> s
BCDE
stepped to DIGITAL\A\%LINE 100
100: one_line := integer_to_text(x,1) + 'A';
DBG> s
stepped to DIGITAL\A\%LINE 101
101: b(one_line);
DBG> s
%SYSTEM-F-RADRMOD, reserved addressing fault at PC=00001516, PSL=03C00004
break on unhandled exception at DIGITAL\A\%LINE 101
101: b(one_line);
DBG> exit
Regards, Drew Sanford
Customer Support Center
RE: C970128-3670
Example to duplicate problem:
program digital(input,output);
type
string = varying [255] of char;
VAR
PARAMCOUNT : INTEGER := 0;
PARAMSTR : [Volatile] ARRAY [1..9] OF STRING := ZERO;
PROCESS_MODE : STRING := ZERO;
[INITIALIZE] PROCEDURE TOOLS_STARTUP_PROCEDURE;
var
X,
status: integer;
symbol, ret_buf: string;
function lib$get_symbol( %descr symbol, ret_buf: string): integer; extern;
begin
{ GET POSABLE PARAMS PASSED BY RUNP}
FOR X :=1 TO 9 DO
BEGIN
CASE X OF
1 : symbol := 'PVP1';
2 : symbol := 'PVP2';
3 : symbol := 'PVP3';
4 : symbol := 'PVP4';
5 : symbol := 'PVP5';
6 : symbol := 'PVP6';
7 : symbol := 'PVP7';
8 : symbol := 'OPER_NAME';
9 : symbol := 'DISC_DATA1';
END;
RET_BUF := '';
status := lib$get_symbol( symbol, ret_buf);
PARAMSTR[X] := RET_BUF;
END;
PARAMCOUNT := 0;
FOR X:=7 DOWNTO 1 DO
IF (LENGTH(PARAMSTR[X]) > 0) AND (PARAMCOUNT = 0) THEN PARAMCOUNT := X;
{IF RUN BY RUNP GET THE PROCESS MODE}
symbol := 'PROCESS';
status := lib$get_symbol( symbol, ret_buf);
IF NOT (ODD(STATUS)) THEN PROCESS_MODE := 'UNKNOWN'
ELSE
PROCESS_MODE := RET_BUF;
end;
FUNCTION Integer_to_Text (Arg: INTEGER; LEN:INTEGER := 6): String;
VAR
Text_value: STRING;
BEGIN
WRITEV(Text_value, Arg:LEN);
Integer_to_Text := Text_value;
END;
function E(temp_str : string) : string;
begin
temp_str := temp_str + 'E';
E := temp_str
end;
procedure d(var temp_str : string);
begin
temp_str := temp_str + 'D';
temp_Str := E(temp_str);
end;
procedure C(var temp_str : string);
begin
temp_str := temp_str + 'C';
d(temp_str);
end;
procedure B(var temp_str : string);
begin
temp_str := temp_str + 'B';
c(temp_str);
end;
procedure A;
var
x : integer := 1;
one_line : string := '';
begin
b(one_line);
for x := 1 to 10 do
begin
writeln(one_line);
one_line := integer_to_text(x,1) + 'A';
b(one_line);
end;
end;
begin
A;
end.
|
| 1829.3 | IPMT priority 2 CLD will be raised | CSC32::D_SANFORD | | Thu Jan 30 1997 18:36 | 215 |
| VERSION INFORMATION:
Product: OpenVMS VAX DEBUG
Product/Component Version: V7.0-000
Operating System Version: OpenVMS VAX Version 7.0
SOURCE: (do not enter - for STARS purposes only)
SYMPTOM:
When using the DEBUG STEP command the debugger sometimes skips over
lines while executing them or fails with a fatal error:
%SYSTEM-F-RADRMOD, reserved addressing fault at PC=00001006, PSL=03C00004
DIGITAL RESPONSE:
This problem has been reported to Engineering.
WORKAROUND:
Downgrade to OpenVMS VAX V6.2.
ANALYSIS:
The example which follows demonstrates two problems. First, when calling
a Pascal function two lines are executed on the step, for example:
Line 35: one_line := integer_to_text + 'B';
Line 36: all_for_one;
In this case when you STEP from line 35 both line 35 and 36 will be
executed and finally stop a line 37.
Second, when calling two functions using a STEP command the debugger may
fail with:
%SYSTEM-F-RADRMOD, reserved addressing fault at PC=00001006, PSL=03C00004
for example:
Line 43: one_line := integer_to_text + 'D';
Line 44: one_line := E(one_line);
In this case when you STEP executing line 44 it will fail with the above
error.
\
\
\ BUSINESS IMPACT:
\
\ Customer satisfaction issue! Given the above problem it is essentially
\ difficult if not impossible to reliably use the DEBUGGER on OpenVMS VAX
\ V7.0. The current ECO did not resolve this problem and the customer is
\ unwilling to downgrade to OpenVMS VAX V6.2 where there is no problem.
\
\
\ CONFIGURATION:
\
\ System Type: N/A
\ Option Type: N/A
\ Memory Size: N/A
\ Installed Patches: N/A
\ Part Numbers: N/A
\ Revision Levels: N/A
\
\ Note: Upon Product Engineering's request, retain failed parts for
\ engineering analysis and problem isolation.
\
\ If the problem is not clearly defined to the hardware/software component
\ and cause, then complete the following:
\
\ o For a network problem, prepare a "complete" network map to be made
\ available to Product Engineering. Examples of Eng Grps:IBM-Interconnect,
\ Pathworks, Networks
\ o For a cluster problem, prepare a "complete" cluster diagram to be made
\ available to Product Engineering.
\ o Prepare a "complete" listing of all third party/Digital products.
\
\
\ CHANGES TO ENVIRONMENT:
\
\ N/A
\
\
\ TESTING INFORMATION:
\
\ Has this issue been reproduced on CSC lab systems? Y
\ Explain: SONRIZ:: OpenVMS VAX V7.0
\
\ Is this issue consistently reproducible at the customer site? Y
\ Explain: Whenever they use the debugger.
\
\ Include the exact steps to reproduce the behavior, including any
\ programs, if the information is not already included above.
\
\ {log file or list of commands}
\ $ PASCAL/NOOPT/DEBUG TEST
\ $ LINK/DEBUG TEST
\
\ $ RUN TEST
\
OpenVMS VAX DEBUG Version V7.0-000
\ %DEBUG-I-INITIAL, Language: PASCAL, Module: DIGITAL
\
\ DBG> STEP/INTO
\ stepped to DIGITAL\A\%LINE 33
\ 33: for x := 1 to 10 do
\ DBG> STEP
\ stepped to DIGITAL\A\%LINE 35
\ 35: one_line := integer_to_text + 'B';
\
\ LINE 36 is skipped over, but executed
\
\ DBG> STEP
\ In routine all_for_one
\ stepped to DIGITAL\A\%LINE 37
\ 37: all_for_one;
\ DBG> STEP
\ In routine all_for_one
\ stepped to DIGITAL\A\%LINE 38
\ 38: all_for_one;
\ DBG> STEP
\ In routine all_for_one
\ stepped to DIGITAL\A\%LINE 39
\ 39: one_line := integer_to_text + 'C';
\
\ LINE 40 is skipped over, but executed
\
\ DBG> STEP
\ In routine all_for_one
\ stepped to DIGITAL\A\%LINE 41
\ 41: all_for_one;
\ DBG> STEP
\ In routine all_for_one
\ stepped to DIGITAL\A\%LINE 42
\ 42: all_for_one;
\ DBG> STEP
\ In routine all_for_one
\ stepped to DIGITAL\A\%LINE 43
\ 43: one_line := integer_to_text + 'D';
\ DBG> STEP
\ stepped to DIGITAL\A\%LINE 44
\ 44: one_line := E(one_line);
\ DBG> STEP
\ %SYSTEM-F-RADRMOD, reserved addressing fault at PC=00001006, PSL=03C00004
\ break on unhandled exception at DIGITAL\A\%LINE 44
\ 44: one_line := E(one_line);
\ DBG> EXIT
\
\ Progam TEST.PAS
\
\ program digital(input,output);
\ type
\ string = varying [255] of char;
\ VAR
\ PARAMCOUNT : INTEGER := 0;
\ PARAMSTR : [Volatile] ARRAY [1..9] OF STRING := ZERO;
\ PROCESS_MODE : STRING := ZERO;
\
\ FUNCTION Integer_to_Text : String;
\ BEGIN
\ Integer_to_Text := 'A';
\ END;
\
\
\ function E(temp_str : string) : string;
\ begin
\ temp_str := temp_str + 'E';
\ E := temp_str
\ end;
\
\
\ procedure all_for_one;
\ begin
\ writeln('In routine all_for_one');
\ end;
\
\
\ procedure A;
\ var
\ x : integer := 1;
\ one_line : string := '';
\ begin
\ for x := 1 to 10 do
\ begin
\ one_line := integer_to_text + 'B';
\ all_for_one;
\ all_for_one;
\ all_for_one;
\ one_line := integer_to_text + 'C';
\ all_for_one;
\ all_for_one;
\ all_for_one;
\ one_line := integer_to_text + 'D';
\ one_line := E(one_line);
\ end;
\ end;
\
\
\ begin
\ A;
\ end.
\
\ If the problem involves a system crash, include the crash analysis here.
\
\ N/A
\
\ Network location of logfiles, crash dump, and all supporting files:
\
\ TURRIS::DEBUG.NOTE, 1829.*
|
| 1829.4 | Pascal source file used in IPMT case for both problems | CSC32::D_SANFORD | | Thu Jan 30 1997 18:38 | 51 |
| program digital(input,output);
type
string = varying [255] of char;
VAR
PARAMCOUNT : INTEGER := 0;
PARAMSTR : [Volatile] ARRAY [1..9] OF STRING := ZERO;
PROCESS_MODE : STRING := ZERO;
FUNCTION Integer_to_Text : String;
BEGIN
Integer_to_Text := 'A';
END;
function E(temp_str : string) : string;
begin
temp_str := temp_str + 'E';
E := temp_str
end;
procedure all_for_one;
begin
writeln('In routine all_for_one');
end;
procedure A;
var
x : integer := 1;
one_line : string := '';
begin
for x := 1 to 10 do
begin
one_line := integer_to_text + 'B';
all_for_one;
all_for_one;
all_for_one;
one_line := integer_to_text + 'C';
all_for_one;
all_for_one;
all_for_one;
one_line := integer_to_text + 'D';
one_line := E(one_line);
end;
end;
begin
A;
end.
|
| 1829.5 | | LOWFAT::DIETER | | Fri Feb 07 1997 14:29 | 4 |
|
working on fix, which we will ECO...
Mary
|
| 1829.6 | soon to be ECOed...here's the story: | SSPADE::SSPADE::HILDE | | Mon Feb 10 1997 09:54 | 35 |
|
PASCAL uses HALTs to trap into its RTL handlers for certain user
application error conditions! That's right, it actually builds
programs with HALT instructions in them. Unfortunately, when it does
this it also uses the byte following the HALT as a sort of error value.
In essence, it turns the one byte HALT instruction into a two byte
"PTRAP #" instruction, which you can see in its listing files.
"PTRAP #", of course, is not a real VAX machine instruction. I don't
see any easy way for DEBUG to realize whether the "HALT" is of 1 or
2 byte length...which means we can't know with certitude where the
next instruction starts! This has caused the debugger problems for
years and years in our instruction decoding and views...all for the
sake of a RTL saving a few bytes over a regular signal/call! PASCAL
is the only compiler that we know of that uses this trick/hack. They
should change this. However, in V7.0 VAX DEBUG stepping also became more
aggressive, i.e. performance enhancement, in instruction look ahead
and breakpoint (BPT) insertions. This performance enhancement, however,
failed to take the PASCAL "length" ambiguity of the HALT instruction
into account. This can result in the debugger planting a BPT
instruction in the wrong place, i.e. overlapping instructions thus
corrupting the code. It can also result in run away steps when the
instruction stream is misinterpreted and the BPT inserted in a wrong
and never executed spot. Since the debugger needs to at least work as
well as it did, we need to fix our behavior as well.
So, I've changed the VAX debugger to TBIT when it sees a step range that
includes a HALT instruction (slow but sure). That is, it does not
optimize stepping performance for such ranges (sigh). BTW, there were
some other problems with this optimize algorythm that were fixed for
later releases, see VAX-GRYPHON QAR 435 (V7.1) and and SPR HPXQB1E56,
alias CFS.46312, (V7.2). So, I've incorporated those fixes into this
CLD fix as well.
Lon
|
| 1829.7 | | TLE::REAGAN | All of this chaos makes perfect sense | Mon Feb 10 1997 13:24 | 31 |
| PASCAL uses HALTs to trap into its RTL handlers for certain user
application error conditions! That's right, it actually builds
programs with HALT instructions in them. Unfortunately, when it does
this it also uses the byte following the HALT as a sort of error value.
True. You do the same thing in MACRO-32 if so inclined.
This has caused the debugger problems for
years and years in our instruction decoding and views...all for the
sake of a RTL saving a few bytes over a regular signal/call!
Its caused you trouble? You have code in their to deal with it? My
observasion is that the debugger had no idea about the HALT,.BYTE
sequence. I remember that PCA had extra code...
Its a little more than just a few bytes, it is also run-time performance.
In the early days, the I-stream caches on the VAX were pretty darn'd small.
Having a 12-byte instruction sequence (a PUSH short-literal, and a JMP with
general addressing mode) that is only taken in the case of an error was
deemed to large to slow down normal code. The HALT,.BYTE sequence was the
shortest (and thereby quickest).
PASCAL is the only compiler that we know of that uses this trick/hack.
They should change this.
Easier said than done. There are 15 years worth of .EXEs lying around that
will still have HALT, .BYTE sequences in them. Changing the compiler
won't make them go away (although you can easily argue that if you are
in a debug-cycle, you are actively compiling your code...)
-John
|
| 1829.8 | yeah, but... | SSPADE::SSPADE::HILDE | | Mon Feb 10 1997 15:04 | 48 |
|
> True. You could do the same thing in MACRO-32 if so inclined.
So? ;-) You can do almost anything you want in MACRO-32, e.g. create
a circular stack,...and get into lots of trouble doing so...doesn't make it
right.
>Its caused you trouble? You have code in their to deal with it? My
>observasion is that the debugger had no idea about the HALT,.BYTE
>sequence. I remember that PCA had extra code...
No, we have no code to deal with it. For instruction display, we simply
decode the "wrong stuff" (off by one byte) and thereby display the wrong
instructions for the address subrange following the HALT to end of the
range requested, e.g. a line's address range. In this case, we got lost
with our step BPT insertions. I'll try to find out what PCS did. The only
thing I can imagine doing is continue decoding after the HALT, at the end
of the range notice that we are off by N bytes, and, if off, go back, pad
the HALT, and decode again. Note that this works most/some of the time...
but it's not guarenteed since while decoding "garbage" we could still end
up landing exactly on the known boundry. Adequate perhaps for instruction
displaying...we could tolerate a small percentage of small subrange
instruction display errors. Not at all adequate for stepping, however...
we can't tolerate any run away steps or RADRMODs, if possible. I suppose
we could special case PASCAL instruction decoding...can you guarentee that
ALL PASCAL HALTs are 2 bytes? Although even that is inconvientent for
stepping since the lookahead code for that is buried deep in the debug
kernel image and far from the debug main image's knowledge of language and
DSTs. Also wouldn't we then have to also remember that the language isn't
really PASCAL after debug user manually says, "SET LANGUAGE PASCAL" or is
really PASCAL...etc.
>Easier said than done. There are 15 years worth of .EXEs lying around that
>will still have HALT, .BYTE sequences in them. Changing the compiler
>won't make them go away (although you can easily argue that if you are
>in a debug-cycle, you are actively compiling your code.
Good point and granted...and it may be quick but I still think it is bogus.
Nothing personnel...really...but as a debugger we depend on interrepting
things according to standards. We must interpret stacks and call frames
according to the OpenVMS calling standards. And, I think, we must decode
instructions according to the SRM definitions. This, of course, is
especially important for VAX where we can't make any assumptions about
where the next instruction starts without analyzing the current one.
Lon
|
| 1829.9 | | TLE::REAGAN | All of this chaos makes perfect sense | Mon Feb 10 1997 21:47 | 12 |
| Yes, any HALT generated by Pascal is followed by a single byte of data.
If its easy, please do whatever you can. However, we've lived this
this for 15 years and it hasn't been a big deal to my knowledge.
Perhaps the debugger has gotten bug reports over the years on this?
As for decoding according to the SRM. Yes, you should do that.
However, given that OpenVMS exception handlers can reset the PC to
darn'd near anything they want, you really don't know where the next
executed instruction will be in all certainty, right?
-John
|