Re: VMS>7.3 Linker Manual - I64 Short Data restriction

Richard Maher wrote:

When could one expect to see a new version of the Linker Utility Reference
Manual available with VMS. The one on the Web and Doc CDs appears to be VMS
7.3 April 2001. All the I64 stuff I've seen is in one of the 8.2 New
Features Manual (Which would make sense if 8.2 was the first supported
itanium version :-) but are we gonna get a new set with 8.3?

Yes, an updated linker manual comes with 8.3.

Also, Can anyone shed any light of possible solutions/work-arounds to the
4MB limit on this Short Data segment thing? (Something other than "Your
app's crap - re-engineer it!" would be nice :-)

In general, filling up the 4MB short section results from compilers asking for too many address constants. Although the short section also contains linker-created function descriptors and static user data 8 bytes or smaller.

As background, on Alpha, each routine is passed a routine-unique pointer to the "linkage" section which contains its procedure descriptor and all the compiler requested address constants. While there isn't a hard limit, the downside is that if multiple compilations need the same address, there are many copies in the final image. On I64, the compilers don't allocate space for address constants, but request that the linker materialize the address for them. It makes the linker more complicated, but it also allows the linker to remove duplicates.

By convention (we didn't 'invent' the convention, it comes from the Intel Run-Time Conventions), this linker-created section of address constants (and function descriptors, etc.) is shared by the whole image. Each routine has the address of this "short" section passed in R1. The short section is accessed with the following instructions:

; Add offset from R1 to the location where the linker
; allocated the address. This form of the 'add' instruction
; is defined to be:
; add Ra = imm22, Rb
; where Rb must be either R0, R1, R2, or R3.
; When the compiler generates the instruction, it usually
; puts a 0 in the 22-bit literal and issues a relocation.
; The relocation tells the linker to create an address to
; SYM, allocate it in the short section, and modify the
; immediate operand of the instruction to have the offset
; from R1 to the allocated address.
add Rn = @ltoff(SYM), R1

; Now that we have the address of the address, fetch it
ld8 Rn = [Rn]

; We can now fetch the static data. It might be something
; readonly like a linker-materialized address or it might
; be some user variable (8 bytes or smaller).
ld8 Rn = [Rn] ; fetch an 8-byte 'thing'

Specifically what, if anything, does the Option File command "SHORT_DATA=NO"
do for us? (Latent support only?)

Doesn't do anything for you.

I have seen the /SEGMENT=(Short_data=WRITE) but another 65K is not gonna
help us and it would be could to avoid any behavioural changes where

You can also try /SEGMENT=SYMBOL_VECTOR=NOSHORT (if you creating a shareable image), avoid /NONATIVE_ONLY (it makes function descriptors larger), and avoid pulling code sections from the default cluster.
However, I wouldn't expect much help from any of these.

There seems to be a fair sprinkling of discussions on the web (Some with
Linux and Windows) but it seems to come down to the compiler having to do it
or you're stuffed?

Will PSECT_ATTR=data,NOSHORT never be allowed?

Can we not CLUSTER/COLLECT out of the SHORT segment hand have the Linker fix
up the "little" address references to real 32-bit ones?

As you can see from my description above, the compiler generated code with explicit knowledge that the data in question (user static data or linker-created addresses/FDs) can be found from an offset from R1. If you tell the linker not to put that PSECT "near" R1, the code cannot possibly reach it.

Given the model used, on I64 you can compile all your modules without any guarantee that you can combine them into one applications.

Right now, I'm working on a COBOL issue where it generates address constants for code labels to use with the PERFORM statement. I have two customers who cannot link due to this. I have prototype COBOL compiler read for testing by one of the customers now. I'm off for a 3 week absense [2-wks vacation, 1-wk business trip]. I'll finish it when I'm return.

Now, for those of you who have read the Itanium ELF ABI to see the complete list of relocations defined, you might notice a handful of relocations that would let the linker fill in the 64-bit literal of a 'movl' (move with long literal) instruction. Such a relocation would eliminate the 22-bit (4MB) short section by just not having a short section. However, the compilers would have to generate different code and the linker would have to implement them. I don't believe that any Itanium linker (Windows, Linux, HP-UX, OpenVMS) implement the larger relocations or do any compilers produce them. It makes the code quite position dependent and would require a $h!t load of image activation time relocations especially for shareable images built that way!

Is your application in COBOL? Other than COBOL, I've yet to see an application that won't link on OpenVMS I64. Of course, knowing the above information, it would be trivial to hand-construct (well, machine-construct) an application that wouldn't link.

John Reagan
HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader
Hewlett-Packard Company