Pascal Compiler VS Debugger

[rodprince]

OpenVMS VMSV9.2-1
VMS Patch = VSI X86VMS VMS921X_UPDATE V1.0

Pascal Compiler Version = VSI Pascal x86-64 X6.3-139 (GEM 50X8H) on OpenVMS x86_64 V9.2-1

Couple of issues in Debugger using Pascal.

1) I can set a break point but execution does not break at that point.
2) I can set and read modular global variables but if I attempt to exam the variables in the debugger all it says is they have been optimized away.

For a simple test case, I created a program main and a module routine. Main has two external calls to routine. A set and get routine. Routine has the set and get routine. I did declare the global variable in routine as [volatile], simply because in our production code, it is volatile due to AST completion routines that can alter the value. Both .pas files were compiled with $pas/noopt/debug and the link was done as $link/debug main,routines

Main Code is:

Code: Select all

program main (input, output);

[external]
procedure rt_set_value( value : integer);
external;

[external]
procedure rt_get_value( var value : integer);
external;

var
  value : integer := 5;

begin
  rt_set_value ( value );
  rt_get_value ( value );
  writeln ("value = ", value:1);
end.

the routine code is:

module routines(input, output);
var
  gv_value : [volatile] integer;

[global]
procedure rt_set_value( value : integer );
begin
  gv_value := value;
end;

[global]
procedure rt_get_value( var value : integer );
begin
  value := gv_value;
end;
end.

1) If you attempt to set a break point at rt_set_value or rt_get_value() the program will not break but execute to completion.

2) If you step into rt_set_value() and try to exam the global value gv_value the compiler will inform you it has been optimized away.

Rod

[jreagan]

I'll triage this tomorrow and reply back

[jreagan]

Yes, I was able to reproduce both issues. I'll add them to the list. We're trying to improve our debug testing right now to cover more of these tests.

John

[rodprince]

First, let me say thank you.

If you want to add another test case:

Code: Select all

program bitmap(input, output);

type
  r_map_type = packed array [1..64] of boolean;
  bet_maps_type = array [1..10] of r_map_type;

var
  runners     : r_map_type := zero;
  bet_runners : bet_maps_type := zero;

begin
  runners[5] := runners[1];
  bet_runners[1] := runners;
end.

1) Build with pas/noopt/debug & link/debug
2) Step into the program and examine runners

Debugger will cough out the following:

%DEBUG-E-INTERR, debugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption

On HP Pascal I64 V6.1-123 On Openvms I64 V8.4, you can examine the runners variable just fine. If you try to examine the bet_runners variable you get the following: %DEBUG-E-INVARRDSC, invalid array descriptor

This was the situation I was actually trying to replicate on X86 to see if it was still an issue.

Rod

[jreagan]

ok, I'll try to get this triaged and taken care of also. Debugger quality is at the top of our list at the moment. Actually, I think we have 5 items at the top of the list

The cross-compiler DWARF generation was rather limited. We did a first pass at the beginning but there wasn't a running debugger so it was all a guess. In addition, the LLVM 3.4.2 backend didn't know about many legal DWARF tags. Now that we're on a much newer LLVM with the native compilers, we can go back and get better DWARF descriptions. For instance, you might notice that Pascal variant records don't work either (also on our list)

Added in 4 hours 1 minute 25 seconds:
I did notice that if you do a

DBG> SET MODULE ROUTINES

in the debugger, then the breakpoints will be caught by the debugger (you might not have a Pascal compiler that gets the module name correct from the PROGRAM statement but instead uses the source filename - we'll refresh the Pascal compiler again soon to pick up that fix and others)