Unable to link due to attribute SHORT - PASCAL

[Hoff]

Is there any that chance that you can get rid of this COMMON-based position-dependent design, and replace it with private or global sections?  COMMONs have always been, are now, and will be, a bag of hurt.   Map the whole thing with a backing file, if that's necessary.  Otherwise, this looks like you might have a bug in Pascal and that's going to involve the support center.

The Pascal equivalent of the C extern model is Alpha-specific, per the doc.

[stephenbrayshaw · Accepted solution]

Thank you to everyone who has helped with this issue especially H.Becker for his identification of CD_COMMON$END as being in the normal section.

The fix for us was to move everything into COMMON and numbered the variables so they remained in the order we required.

We also created a PSECT with a packed byte array to line up the section to a page boundary.

If you do not line it on a page boundary then crmpsc syscall will fail with an invalid argument error

Examples below:

MEMORY_PAGE_TYPE  = PACKED ARRAY [1 .. MEMORY_PAGE_LEN] OF BYTE;

** Start file **

SharedAreaStartAlign : [GLOBAL, VOLATILE, PSECT(CD_COMMON)] MEMORY_PAGE_TYPE;
SharedAreaStart : [GLOBAL, VOLATILE, COMMON(CD_COMMON_000)] INTEGER;

** CD_COMMON file **

CheckData : [GLOBAL, VOLATILE, COMMON(CD_COMMON_001)] CHECK_DATA_TYPE;

GlobalCreateTime : [GLOBAL, VOLATILE, COMMON(CD_COMMON_002)] DAI_TIME_TYPE;

** End file **

SharedAreaEnd   : [GLOBAL, VOLATILE, COMMON(CD_COMMON_999)] MEMORY_PAGE_TYPE;

[H.Becker]

Just to wrap up what I found when I had access to an I64 with Pascal installed. If you have source modules like

$ type %.pas
 
DISK$USER:[USER]A.PAS;1
 
module a;
var
  start : [global,psect(cd_common)] integer;
end.
 
DISK$USER:[USER]B.PAS;1
 
module b;
var
  whatever : [global,psect(cd_common)] integer;
  data : [global,psect(cd_common)] array [1..2048] of integer;
end.

 
DISK$USER:[USER]C.PAS;1
 
module c;
var
  last : [global,psect(cd_common)] array [1..2000] of integer;
end.
$ 

$ pas a
$ pas b
$ pas c

You end up with short data sections in a.obj and b.obj:

$ pipe analyze/obj %.obj |search sys$pipe common
    5.  NOBITS               CD_COMMON                         00000000000000F0 0000000000000004  WA------Sho-------------------
    5.  NOBITS               CD_COMMON                         00000000000000F0 0000000000002008  WA------Sho-------------------
    5.  NOBITS               CD_COMMON                         00000000000000F0 0000000000001F40  WA----------------------------
$

It seems like Pascal determines whether the data should be in a short data section based on the first variable in a module with attributes, specifiying the PSECT name.

I didn't find any other attribute to force data out of short data and there seems to be no directive or qualifier to avoid short data. Given the SOLITARY option for the linker, some code may expect the first data (here variable start) being on a page boundary. So what can be done is to make the first variables bigger than "short" - prefix with unused data in module a and change the sequence in module b:

$ ty a.pas
module a;
var
  unused : [global,psect(cd_common)] array [1..8192] of char;
  start : [global,psect(cd_common)] integer;
end.
$ ty b.pas
module b;
var
  data : [global,psect(cd_common)] array [1..2048] of integer;
  whatever : [global,psect(cd_common)] integer;
end.

$ pas a
$ pas b
$ pipe analyze/obj %.obj |search sys$pipe common
    5.  NOBITS               CD_COMMON                         00000000000000F0 0000000000002008  WA----------------------------
    5.  NOBITS               CD_COMMON                         00000000000000F0 0000000000002008  WA----------------------------
    5.  NOBITS               CD_COMMON                         00000000000000F0 0000000000001F40  WA----------------------------
$ 

[John Gillings]

I'd have hoped that multiple modules mapping to the same common data would have identical definitions of that data, which would presumably mean that the PSECT attributes would be the same? 

To have anything other than identical definitions (and preferably a single source of text, using whatever langauge constructs are available), is setting yourself up for errors somewhere sometime. I present this post as evidence!

I'd have further hoped that in 21st century, we'd be using better, safer data sharing mechanisms than overlaid common blocks. That you have to fiddle around with dummy variables to align things in the right place should be ringing alarm bells that it's not a good way to achieve your objectives.

This is a good illustration of the general rule "never lie to a compiler". When a compiler gets conflicting descriptions of the same object, it shouldn't be surprising that it generates conflicting implementations of that object. 

[H.Becker]

> I'd have hoped that multiple modules mapping to the same common data would have identical definitions of that data, which would presumably mean that the PSECT attributes would be the same? 

Common data? There is no COMMON in my example other than the misleading name CD_COMMON. A COMMON is different and has different attributes, like:

$ ty x.pas
module x;
var
  start : [global,common(psect)] integer;
end.
$ 

Yeah, just for fun I gave the COMMON the misleading name PSECT.

$ pas x
$ pipe analyze/object x |search sys$pipe psect
    6.  NOBITS               PSECT                             00000000000000F0 
0000000000000004  WA------------GblOvr----------
$ 

And, as you  can see, this will not go into short data and the section has the PSECT attribute OVR.

> I'd have further hoped that in 21st century, we'd be using better, safer data sharing mechanisms than overlaid common blocks.

The OP said this is a port from Alpha, which has the 21 in the processor model numbers but not automagically in the SW designs :-) Who knows, maybe the SW was written for VAX. And who knows what the reasons were to port this code to I64 - but very likely there was some hope that the port would be easy and would not require a re-design or re-write.

> This is a good illustration of the general rule "never lie to a compiler".

Probably true, but I can't see that the rule was violated, here.

That said and not knowing why this code was written that way, no question, I would have written it differently - or maybe would have lied differently :-)

[stephenbrayshaw]

Thanks once again H.Becker for your continued help.

We have now changed it all back to how it was and then changed the start value in CD_COMMON$START from an integer to a packed array oy bytes that is exactly a page long.

This has then put all of the variables into a normal section and with much less work to change the code.

To give some idea as to why this mechanism is still used in the 12st century it is because the software was originally for vax before moving to microvax and then alpha.

During each migration we make a few changes as possible for stability reasons.

We do not ever force our customers to upgrade to the latest version of our software and due to the industry we work in it is VERY important that we do not do that.

Our new systems work differently than these old systems but are only available for Linux / AIX

[John Reagan]

Gee, I don't look here for a week and along comes a Pascal question.  Nobody thought to email me?

Yes, Harmut figured it out.  The first variable placed in the PSECT determines the 'shortness'.  That is a bug which I thought I described in the release notes about the time I transitioned off of the VMS compilers.   Looking back, we should have extended the PSECT attribute to make the shortness explicit.

Adding something to the front that is larger than 8 bytes should do the trick.  I can fix it on the VSI compiler side.  I can't speak for HP.

I'll also update the release notes.