x86-64 Pascal problem

[arne_v]

I did not expect this:

Code: Select all

$ type z5.pas
program z5(input, output);

type
   pstr = varying [1812] of char;

procedure test1(xmlstr : pstr);

begin
    writeln(xmlstr);
end;

begin
    writeln('start');
    test1('<methodResponse>' +
          '<params>' +
          '<param>' +
          '<value><i4>123</i4></value>' +
          '</param>' +
          '</params>' +
          '</methodResponse>');
end.
$ pas z5
$ link z5
$ r z5
start
<methodResponse><params><param><value><i4>123</i4></value></param></params></methodResponse>
$ type z6.pas
program z6(input, output);

type
   pstr = varying [1813] of char;

procedure test1(xmlstr : pstr);

begin
    writeln(xmlstr);
end;

begin
    writeln('start');
    test1('<methodResponse>' +
          '<params>' +
          '<param>' +
          '<value><i4>123</i4></value>' +
          '</param>' +
          '</params>' +
          '</methodResponse>');
end.
$ pas z6
$ link z6
$ r z6
start
%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual address=000000007ACDA000, PC=FFFF830009A4B279, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image     module    routine               line      rel PC           abs PC
LIBOTS                                       0 0000000080002279 FFFF830009A4B279
z6  Z6  TEST1                                6 000000000000008F 000000008000008F
z6  Z6  Z6                                  14 000000000000005B 000000008000005B
                                             0 FFFF8300081FC0A6 FFFF8300081FC0A6
DCL                                          0 00000000800677FB 000000007ADFF7FB
%TRACE-I-END, end of TRACE stack dump

What happen when the varying goes from 1812 to 1813??

Added in 46 minutes 9 seconds:
And:

$ pas/ver
VSI Pascal x86-64 V6.3-143 (GEM 50XC4) on OpenVMS x86_64 V9.2-2

Added in 22 minutes 6 seconds:
In the real program I got other errors with 1800. But it worked with 800. So the 1812-1813 difference seems to depend on the specific context.

Not sure how useful this note is, but ...

Added in 17 minutes 41 seconds:
And the real program works fine on Alpha with 32000.

[jreagan]

Interesting. Note that the failing PC of 07ACD8000 is on a page boundary.

For Z6/test, I see the compiler saving the old sp and allocating 1816 bytes on the stack

Code: Select all

00000071:  movq    %rsp,%rbp
00000075:  subq    $00000718,%rsp

and then we pass the address 8 bytes beyond the "top" of the stack to OTS$MOVE and ask it to copy 1815 bytes

Code: Select all

0000007F:  leaq    -00000720(%rbp),%rdi
00000086:  movl    $00000717,%esi
0000008B:  callq   OTS$MOVE@PLT

if that stack page doesn't exist (and beyond the top of the stack) and we get an ACCVIO, it seems that the system doesn't do "stack extension" and gives the ACCVIO back.

I'll enter a bug report.

[arne_v]

So it is a VMS problem not a Pascal problem - if I tried playing with large stack variables in C then I would eventually hit the same problem?

[jreagan]

No, since we touched an address past the end of the stack pointer, I don't expect the OS to extend the stack. I might have implied that I was expecting it to do so.

It might turn into an OS question at some point with regards to "red zones" on x86 but we turn those off and always move the stack pointer and always set the frame pointer.

[arne_v]

OK. So I am waiting for a new Pascal compiler.

[jreagan]

Finally tracked this down. The code in the routine didn't use the current length of the VARYING string to make the local copy, it used the max length by mistake. We've fixed it. Not sure when we'll make the next Pascal kit (which would technically be the 1st FT for a future V6.4 kit). I'm just back from holiday and will start to plan it out.