%ILINK-E-NOT22BITS error (not resolved with /NATIVE)

[Dmitry V. Sinelnikov]

Hi Folks,

I have a project originally written, compiled and linked on Alpha. I am trying to port it to Itanium and faced the subject error while linking some modules.

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

I found a branch here with discussion (http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=605424) which addresses exactly the same issue and it has some kind of workaround – to use /NATIVE option for linker. I redefined ‘link’ command in the following way:

link :== link/NATIVE

and rebuilt the whole project from scratch. In fact it didn’t help and the issue still occurs for the same images. These images are built from ~1500 modules. BTW, I have noticed that average image size on Alpha is about 100Mb. Those images which were linked successfully on Itanium are twice this size (>200Mb).

Some info on my system is below:
1) Linker version is the following:
$ cc /version
HP C V7.2-001 on OpenVMS IA64 V8.3-1H1

2) String for compiler (legacy of Alpha code):
$ show sym ccc
CCC == "CC/G_FLOAT/STAND=VAXC/DEF=VAX/NOMEMBER_AL/NOOPT"

Any input is much appreciated.

Best regards,
Dmitry Sinelnikov

[H.Becker]

You very likely can't do much to get this image linked as it is. You should contact HP. You probably need help to determine the underlying problem and to resolve it.

The linker is only the messenger, the problem is too much data to be collected or created to fit in a 4MB virtual address space.

Collected are short data sections created by the compilers. Short data may be a longword for an int or smaller items. The compilers decides. Relocations, produced by the compilers, require the linker to create data. Created data are address data and function descriptors. The error code indicates the linker tries to create that data and hits the 4MB limit.

The limit of 4MB is imposed by the set of IA64 instructions, which the compiler used to create code.

That said, when linking, you can
- for shareable images, move the symbol vector out of short data:/SEGMENT=SYMBOL_VECTOR=NOSHORT
- for a test, combine readonly and writeable short data: /SEGEMENT=SHORT=WRITE

The other option is to check how much short data sections the compiler generated and, if it is much, to try to reduce that.

That may require a simple re-compile with a different external data model or may require code changes to move some of the short data into bigger ones. Unfortunately there is no compiler switch to tell what or how much the compiler should put into short data sections.

And, there is no easy way to estimate how much short data will be used based on what you have on Alpha. (The size of the image and that it is twice the size of Alpha doesn't mean anything for short data.)

[H.Becker]

One more thing, try to avoid multiple code segments. That is, no CLUSTER= optios, try to use the default linker cluster with all your code and data.

[Dmitry V. Sinelnikov]

Thank you.
Switching to

link:==link/segment=short=write

changed error description. Now it has another 'relocation section', 'relocation type', 'relocation entry' and 'module' eventually. But in fact the issue still persists.

Talked to the code-author, he said he had the same issue with Itanium platform long time ago and it was 'cured' by splitting images into several parts. Will put the details here once he gives me some more info but it seems you are write and I have to change either linking procedure or the code structure itself.

[John Reagan]

You didn't hear this from me :), but try /SWITCH=REDUCE_RELOCATIONS on the C command. That is an undocumented qualifier to tell the code generator that instead of asking the linker to produce addresses for things like "psect+10", it will only ask for the base address of "psect" and do the "+10" at run-time. We added this for large COBOL applications (REDUCE_RELOCATIONS is enabled by default for COBOL and it is a documented option for Pascal).

[Dmitry V. Sinelnikov]

Finally the issue has been resolved. As I already mentioned code-author had a special instruction to workaround this Itanium specific issue. For those interested here is some check points of this "how to":
- perl script parses source code and moves all GLOBAL variables to one file to avoid duplicating it in every module
- once modules are compiled into *.olb files - another script (regular openvms batch script) extracts all RDB modules from these *.olb into one separate olb library and then compiles shareable EXE modules.
- final step is compiling necessary servers with these shareable EXE modules. As a result instead of 10 * 150Mb servers we have ~10 * 50 Mb servers + ~20 shareable EXE modules which must be installed using "$instal replace/share" expression...

Somewhat non-trivial after all... but it seems to be the only way to avoid huge code changes in a big project and make compilation process only slightly different from what is used on Alpha platform.
Hopefully it will give some hints to those who will face the same issue.

[Hein van den Heuvel]

Dmitry, Thank you for a clear and complete follow up!
And Hartmut and John, thanks for the detailed background as as always.
This has become one of the better topics ever.
Gem's like this make it worthwhile to spend some time here.
Regards,
Hein.

[Willem Grooters]

IIRC, this was mentioned on a bootcamp as well: if you have a big (monolithic) program, split it up into shared images, just to prevent this issue.