%ILINK-E-NOT22BITS error -- how to solve?

[David B Sneddon]

Hi Folks,

I am trying to port code to Itanium. The code
compiles OK but when I link I get

%ILINK-E-NOT22BITS, the short data segment has exceeded 4MB
%ILINK-E-NOIMGFIL, image file not created

I can't find anything on the "short data" segment
and the Itanium porting guide mentions setting
the linker option SHORT_DATA=WRT (or NOWRT) to
possibly prevent this overflow.

The image in question is 150MB on Alpha and a
map generated for the Itanium link indicates a
size of 420MB (not my code or application design,
I'm just trying to get it to build).

Questions:
What is the short data segment?
Can its allocation be controlled?
Is resolving this issue going to involve lots
of code/application redesign?
(If the answer to the last one is YES, then I
need to know so I can let the developers know
they have a small job to do.)

Regards
Dave

[Willem Grooters]

Dave,
For what I've learned:

Short data segment is part of the new exe format. What is contains exactly, I don't know, maybe it has to do with UNWIND in case of error (this hes been changed drastically compared with AXP and VAX). It's allocation can NOT be controlled (prescibed by the standard).
Whether it requires a lot of recoding cannot be stated without knowlegde of the application. It may, or may not.

Check the following link:

http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/resources.html for information of porting to Itanium.

[David B Sneddon]

Willem,

I have just been looking through the Calling Standard
and found a description of the short data segment.
It is related to the linker collecting small
items (less than 8 bytes) and putting them in
the short data area so that addressing them
is done using a short direct addressing sequence
rather than indirect addressing.
One is directed to the Linker Manual for more
information on images and clusters but I am
still unclear as to how I can gather this data
into different clusters within the image.

Dave

[Willem Grooters]

Dave,

This "short data segment" is just one area, prescribed by the standards (ELF, I reckon) so I think you have no real control over it,
nor will you have control over this section's protection. (There has been some changes in protections as well!)

You may be able to put at least part it into one or more other sections.

Willem

[Willem Grooters]

Dave,

Dug somewhat deeper.
Image section (ISECT) on AXP is named "Segment" on IA64. Just for clearence:

"Short Data" segment on Itanium can be compared with "Linkage" section on Alpha. The ReadOnly data held in the section on AXP is now in a separate segment (RO data) in IA64.
I also found that the footprint of the code segment on IA64 is about 3 times the one on AXP - based on the very few examples I've seen.

IIRC, "Short Data" is determined by the linker so I very much doubt you have influence on the placement. As said before, you may able to do so by explicitly locate the data in a separate section. If not - that means trouble.

Something for HP to clarify 9and solve....):
I've heard nor read anywhere about this 4Mb limitation on ShortData segment. If it is, HP should supply methods to overcome this.

Willem

[David B Sneddon]

Willem,

The limit of 4MB is detailed on pages 4-57 and 4-58
of the HP OpenVMS Calling Standard (Dec 2003).
I am looking at breaking this image into smaller
shareable images which I suspect is the only
way it will get resolved.

Dave

[Willem Grooters]

Well, I didn't yet read into the document. You're right.

But this section also states:


This allows for up to 256,000 individually-named variables and functions. If an image requires more than this, linker options may
be used to divide the image into multiple clusters (see Section 4.7.1).


So there _should_ be a way to get this done without braking up the image - as described in 4.7.1:


Optionally, an image may be
partitioned into subcomponents called clusters in which case each cluster may
have its own associated data segment (clusters may also share a common data
segment). For further information on images and clusters, see the OpenVMS
Linker Utility Manual.


Though I wonder whether this manual already exists for Itanium....

(Are you planning te describe and share your experiences? I guess quite a lot of people would appriciate that!)

Willem

[David B Sneddon]

Willem,

I will certainly share my experiences with this issue,
unfortunatetly the reference to the Linker manual
does not explain how to specify data such that it
does not end up in the "short data segment" which
is the heart of the problem.
Initial attempts at breaking up the image into
smaller shareable images is proving somewhat difficult
due to the call hierarchy of the program. It will
require a major rework of the code.

Dave

[Walter D. Arbo · Accepted solution]

Dave,

The short data segement contains 1) procedure descriptors (i.e. linkage), which the linker creates on IPF 2) pointers to long or short data which the linker creates in response to relocations in your code 3) data less than a quadword in length which the compilers have put in sections labelled "SHORT".

There is only 1 short data segment per image (composed actually of two segments which have to be relocated together by the image activator). The short data segement is accessed by offsets to the GP (Reg. 1), and the GP is set to an address by the image activator at image activation. The GP points to the middle of the (two) short data segment. Code can then access data with an offset to the GP instead of with a full address.

You don't say what linker you are using, but we made an adjustment that dramatically decreases the amount of short data by pooling the addresses.

Essentially the error NOT22BITS is fatal - if you get that error there is nothing that the linker can do to link the image. You are correct - you are left to either 1) move some of the compiler data out of short data or 2) break the image into several shareable images.

Not many customers will hit this error - in fact I've been looking for one since we started. We'd like to help you through this porting problem. Can you contact me directly through mail? I'd like a map of the image (if you have one) and some knowledge of what languages you are using.

-Walt Arbo
VMS/IPF Object/Images Project Leader
Hewlett Packard

[Cass Witkowski]

This almost makes me recall days of PDP and overlays

[David B Sneddon]

Walt,

The code is mostly BASIC with a few Macro and C routines.
Yes I can send you a map from the linker.
The Linker is I01-60.
What is your email address?

Dave

[Walter D. Arbo]

Dave,

Please email me at "walt dot arbo at you-know-where dot com".

-Walt

[David B Sneddon]

A quick update...

The procedures used for building the image are the
same ones as used on Alpha. They use /NONATIVE_ONLY
on the link command. By using /NATIVE on the
Itanium link I was able to get the image to build.
The size of the short data segment is just under
the 4MB limit and there are still bits of code
that need to be linked so I suspect it will blow
up again.
In testing the use of sharebale images the following
was noted:
there are 1054 modules in this image,
using /NATIVE gives 257264 bytes of SDATA,
using /NONATIVE gives 2464576 bytes of SDATA.

Thanks to Walt we may be getting more current
linker and compilers which should improve the
situation.

Dave

[David B Sneddon]

A big thankyou to Walt Arbo and John Egolf for
providing access to a later VMS build and newer
BASIC compiler.
The program in question is built from over 5000
modules and the problem is that linking with
/NONATIVE (as a hangover from the Alpha build
environment) causes the SDATA segment to exceed
the 4MB limit. Linking with /NATIVE allows it
to link successfully however the SDATA segment
is still 90% full which means that it probably
won't take too much more to cause it to blow up.
The next step is to split the image into smaller
shareable images. Our development manager has
been advised of this and the required changes to
the code to make this work.

Again, Walt and John have been a great help
in sorting this out.

Dave.

[David B Sneddon]

This issue has been resolved.

Dave