Does it exist Linker limits when linking with an object library (I64) ?


Topic author
l.cedric
Valued Contributor
Posts: 51
Joined: Thu Jul 18, 2019 8:18 am
Reputation: 0
Status: Offline

Does it exist Linker limits when linking with an object library (I64) ?

Post by l.cedric » Thu Sep 24, 2020 10:16 am

Hello,

we are trying to rework our build tools. We wish to use just 1 object library for the whole modules (~ 4000 modules and ~ 83000 symbols) of our application, which will make our link process easier.

But but we are facing this link (or cxxlink) issue :(
link.png
Remarks :
  • If needed, find the tools versions in the above screeenshoot
  • Note the size of our library.
Doubtless, i did not search enough (?), but for our I64 server, I did not find any limits neither for the size, nor number of module or symbol limits :?:

Perhaps a clue / Linker ? ($ sh mem/unit=byte)
linkMem.png
So twice ~ 1 GB ... before the crash ? Is it due to a sort of weird P0 space limit of the i64 Linker ? But I can't understand, as we are on I64 architecture.

Or perhaps a hidden switch to allow the Linker to work with a big library ?

Anyone have any ideas on what to do ?
Thanks for any help.


sms
Master
Posts: 310
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: Does it exist Linker limits when linking with an object library (I64) ?

Post by sms » Thu Sep 24, 2020 11:52 am

Code: Select all

> Anyone have any ideas on what to do ?

      help /message %ILINK-F-MEMFUL


Topic author
l.cedric
Valued Contributor
Posts: 51
Joined: Thu Jul 18, 2019 8:18 am
Reputation: 0
Status: Offline

Re: Does it exist Linker limits when linking with an object library (I64) ?

Post by l.cedric » Fri Sep 25, 2020 2:56 am

Thanks, it's the 1st thing we've done.
Our Administrator gave us on the server VIRTUALPAGECNT 341000000 and PGFLQUO 7200000 for my account.
And please note in the 2nd screenshoot that ~1 GB left (physical memory) not 0.

And the image we want to build has already been well built by the linker, BUT with a precise object list, not as we want to do now : to let the linker doing its job = get the right objects in the big pioche.olb

To reformulate :
The question is not really about our image but how the linker work with a ~ 500 MB library on a I64 architecture, so a huge 64-bits address space (not a 32-bits one with a 4 GB limit), compare to our very few 500 MB ;)
And it's why we think about perhaps some linker limits ? (by design and/or was not rewrite for the I64 architecture ?)

(Now we're trying to split pioche.olb into few piocheX.olb, but as we will need them all for the link, i doubt it solve something)

User avatar

volkerhalle
Master
Posts: 196
Joined: Fri Aug 14, 2020 11:31 am
Reputation: 0
Status: Offline

Re: Does it exist Linker limits when linking with an object library (I64) ?

Post by volkerhalle » Sat Sep 26, 2020 4:31 am

Hi,

I've communicated with someone, who knows the OpenVMS I64 Linker quite well ;-) First comments are:

- it should work
- without access to the .OLB everything is mostly speculation...

But he are a couple of additional thoughts:

- the linker uses virtual memory, most of it from P2 space, but also something from P0 (for symbols). If it runs out of virtual memory, it will try to close files or unload .OLB modules from memory. If the object modules have been compiled in the same way, it shouldn't matter, whether they are in separate files or in an .OLB.

- VIRTUALPAGECNT is obsolete ! PGFLQUOTA may matter, the 'Link Run Statistics' information at the bottom of the linker MAP file may show more information. Just use $ LINK/MAP ...

- also try SHOW PROCESS/ACC after the %ILINK-F-MEMFUL message and check Peak virtual size against the free PAGEFILE size

- try using $ SHOW PROC/CONT/INTER=1/ID=<pid of process running linker> and watch the virtual address space usage after typing 'V'

- the information about CXX$LINK version is irrelevant. Use $ analyze/ima sys$system:IA64_LINK.EXE/sele=id=image

- you could also try to monitor the process header of the process running the linker with SDA:
$ ANALYZE/SYSTEM
SDA> SET PROC/ID=<pid of process running linker>
SDA> SHOW PROCESS/PHD
... repeat above command and look for changing values ..
SDA> EXIT

Volker.
Last edited by volkerhalle on Sat Sep 26, 2020 6:45 am, edited 4 times in total.

User avatar

volkerhalle
Master
Posts: 196
Joined: Fri Aug 14, 2020 11:31 am
Reputation: 0
Status: Offline

Re: Does it exist Linker limits when linking with an object library (I64) ?

Post by volkerhalle » Mon Sep 28, 2020 3:15 am

Hi,

for the future, please do not post screenshots of OpenVMS error messages, but post the messages as text as they appear on the terminal screen. While this increases the chance of copy & paste errors, posting screenshots defeats the purpose of web searching for those messages.

The error message you've reported is:

%ILINK-F-MEMFUL, insufficient virtual address space to complete this link
-SYSTEM-W-REGISFULL, specified region is full

PGFLQUOTA is not a problem, as you will get the following error message, if PFGLQUOTA is too small:

%ILINK-F-MEMFUL, insufficient virtual address space to complete this link
-SYSTEM-F-EXPGFLQUOTA, exceeded pagefile quota

I've created a little DCL procedure to try to reproduce this problem. The procedure automatically creates the source modules, compiles them and inserts them into an .OLB. Then it LINKs the image both from individual .OBJ files and also using the .OLB:

$ pipe libr/lis olb | search sys$pipe "ELF OBJECT"/WIND=(0,10)
Directory of ELF OBJECT library DSA64:<VMS_FORUM.ILINK_MEMFUL>OLB.OLB;3 on 28-SEP-2020 08:17:05
Creation date: 27-SEP-2020 14:56:35 Creator: Librarian I01-29
Revision date: 27-SEP-2020 18:48:02 Library format: 6.0
Number of modules: 3930 Max. key length: 1024
Other entries: 86460 Preallocated index blocks: 213
Recoverable deleted blocks: 0 Total index blocks used: 5741
Max. Number history records: 20 Library history records: 20

Directory DSA64:<VMS_FORUM.ILINK_MEMFUL>

OLB.OLB;3 611.11MB

LINKing works for both cases ! (OpenVMS I64 V8.2, Linker Image Identification "I02-17")

Needed to increase PGFLQUOTA from 700000 to 2000000. LINK with .OBJ used 1500000 peak virtual size

SDA> SHOW PROC/PHD showed first free P0 space address: 00000000.276c8000 (about 66% used of maximum P0 space of 0.3FFFFFFF = 1 GB), about the same value for both LINK operations (with 3929 modules, 82509 symbols, 580 MB .OLB)

Using LINK/MAP does not help analyzing this problem, as you won't get a .MAP file, if the LINK operation fails.

$ SHOW PROC/CONT 'V' does not help, as P0 space usage is too big to fit on the screen.

I'll try to experiment using SSLOG to find the actual failing system service (using the EXPGFLQUOTA scenario).

Volker.
Last edited by volkerhalle on Mon Sep 28, 2020 3:18 am, edited 1 time in total.


Topic author
l.cedric
Valued Contributor
Posts: 51
Joined: Thu Jul 18, 2019 8:18 am
Reputation: 0
Status: Offline

Re: Does it exist Linker limits when linking with an object library (I64) ?

Post by l.cedric » Mon Sep 28, 2020 4:36 am

Thank you very much Volker!
(I keep in my mind your post recommendations about the screenshoots)

I did not try yet all your commands, but here's what i can quickly answer :
  • $analyze/ima sys$system:IA64_LINK.EXE/sele=id=image
    SYS$COMMON:[SYSEXE]IA64_LINK.EXE;1
    "I02-38"
  • I don't see exactly what you mean by "If the object modules have been compiled in the same way, it shouldn't matter", but nevertheless here's some informations : All our modules in this library are compile from C, C++, SQLMOD, .PC, .MSG, and .IFDL and give ELF modules. Of course, the command for the "compilation" is not the same for the whole.
From my side, i found perhaps some clues which could explain some strange Linker behaviours:
  • All our modules was replaced like this : $lib/replace /selective_search (an option said in the documentation as increasing the Linker efficiency ... :? ). My yesterday try, was to replace them whithout this option and ... anymore the crash (%ILINK-F-MEMFUL), but it gave me few undefined symbols ! Which is correct, indeed, few modules were missing in our library. I'll try to fix our (new) build system (Alpha version ... ;) ) and keep you informed, of course.
  • It seems to be like an old issue we still have with the Linker since decades : Before, we do not use any library but give to the linker the precise objects list in an .opt file. The issue is when an object is missing in the .opt, the Linker takes ~100% CPU and does not end, but no crash :!: Perhaps the ~same behaviour but with a libraray :?:
Cédric

User avatar

volkerhalle
Master
Posts: 196
Joined: Fri Aug 14, 2020 11:31 am
Reputation: 0
Status: Offline

Re: Does it exist Linker limits when linking with an object library (I64) ?

Post by volkerhalle » Mon Sep 28, 2020 5:39 am

Cédric,

'compiled in the same way' means: the same compile switches have been used in the individual compilation of each module whether it exists as an .OBJ file or has been inserted in the .OLB. This was to clarify, that the modules in the .OLB have not been complied in a different way (i.e. adding /DEBUG).

In my reproducer, the 3930 modules are all plain C files, as they are being generated automatically: 3 routines and 19 global data symbols each.

Could you please clarify your following sentence: My yesterday try, was to replace them whithout this option and ... anymore the crash (%ILINK-F-MEMFUL), but it gave me few undefined symbols ! Did it crash or didn't it ???

As I now have a tool to easily try to reproduce your scenario, I could easily try LIBR/REPLACE/SELECTIVE to see, whether this would cause the error. And I can easily just remove one .OBJ file from the linker options file used for linking.

SSLOG:

One can turn on SSLOG (System Service Logging) in/for the process running the LINK command to find the actual failing system service, but it generates a HUGE amount of data, which is hard and time consuming to analyze. I tried this with the EXPGFLQUOTA scenario and I see about 60 (failed) entries like this, before the LINK failed:

SYS$EXPREG_64 sts: 00002a2c acmode: U !08:43:35.50
image: IA64_LINK+00041f10 argct: 06
arg 1:000000007ad17918 2:000000002475c000 3:0000000000000003
arg 4:0000000000000000 5:000000007ad17908 6:000000007ad17900
entry number: 00801942 number at completion: 00801942

Argument #2 in an $EXPREG_64 call is:

length_64

OpenVMS usage:byte count
type: quadword (unsigned)
access: read only
mechanism: by value
Length of the virtual address space to be created. The length
specified must be a multiple of CPU-specific pages.

While observing the process running the LINK command, I saw first free P0 space address: 00000000.276c8000. If an $EXPREG_64 with length_64 = 2475c000 would have been issued at that time, P0 space would have certainly been exceeded, maximum is 00000000.3FFFFFFF ! The value 2475c000 may even be the current size of P0 space instead of the length_64 desired to extend it ?!

Volker.


Topic author
l.cedric
Valued Contributor
Posts: 51
Joined: Thu Jul 18, 2019 8:18 am
Reputation: 0
Status: Offline

Re: Does it exist Linker limits when linking with an object library (I64) ?

Post by l.cedric » Mon Sep 28, 2020 6:49 am

ok now i understood for 'compiled in the same way'.

/ 'Could you please clarify your following sentence'
Ok i try to reformulate :
  • Since the beginning, in our new build system we wished to use the selective_search option with the library
  • So we use it and each of our ~ 4000 modules were inserted in the library like this :
    • $lib/repl/selective_search obj:pioche.olb obj:module.obj
    • And when i try to use this library with the Linker, it stops with the fatal error %ILINK-F-MEMFUL
  • Yesterday, i updated our build system to not use this option (just for a try), and so our ~ 4000 modules were inserted in a (new) library like this :
    • $lib/repl obj:pioche.olb obj:module.obj
    • And now the Linker stops with the more obvious (classic) error 'undefined symbols' => which is a far more better way to indicate my issue. Indeed thanks to this error i can see that few modules are missing in the library => which is correct after some investigation in our sources = by mistake, we forgot few modules.
Cédric

User avatar

volkerhalle
Master
Posts: 196
Joined: Fri Aug 14, 2020 11:31 am
Reputation: 0
Status: Offline

Re: Does it exist Linker limits when linking with an object library (I64) ?

Post by volkerhalle » Mon Sep 28, 2020 7:31 am

Cédric,

are you saying, that the linker stopped with %ILINK-F-MEMFUL, WITHOUT previously issueing %ILINK-W-USEUNDEF messages about undefined symbols ?

Note that NOW (when using .OLB without /REPLACE/SELECTIVE), your linker does not STOP, but it completes and creates an .EXE file, but with some undefined symbols ! This is a different behaviour than stopping/exiting with %ILINK-F-MEMFUL and NOT creating an .EXE file !

I've just deleted one module from my test .OLB (now created with LIBR/INSERT/SELECTIVE) and I get 3 %ILINK-W-USEUNDEF (from the missing module) pretty fast, but the link continues and completed without error and created an .EXE file.

Volker.


Topic author
l.cedric
Valued Contributor
Posts: 51
Joined: Thu Jul 18, 2019 8:18 am
Reputation: 0
Status: Offline

Re: Does it exist Linker limits when linking with an object library (I64) ?

Post by l.cedric » Mon Sep 28, 2020 7:45 am

volkerhalle wrote:
Mon Sep 28, 2020 7:31 am
are you saying, that the linker stopped with %ILINK-F-MEMFUL, WITHOUT previously issueing %ILINK-W-USEUNDEF messages about undefined symbols ?
YES :!: (as you can see in my 1st screenhoot above)
volkerhalle wrote:
Mon Sep 28, 2020 7:31 am
Note that NOW (when using .OLB without /REPLACE/SELECTIVE), your linker does not STOP, but it completes and creates an .EXE file, but with some undefined symbols ! This is a different behaviour than stopping/exiting with %ILINK-F-MEMFUL and NOT creating an .EXE file !
YES again :!:
And here's the error (whithout a screenshoot ;) )

$link obj:psf_scat_common_tools.obj, obj:pioche.olb/lib
%ILINK-W-NUDFSYMS, 3 undefined symbols:
%ILINK-I-UDFSYM, TEST_ADR_ECRIT
%ILINK-I-UDFSYM, TEST_ADR_LECT
%ILINK-I-UDFSYM, TEST_ADR_LONG
%ILINK-I-UDFSYM, VMH$FIXEDQ_UR (Weak Reference)
%ILINK-I-UDFSYM, VMH$FIXEDQ_UW (Weak Reference)
%ILINK-I-UDFSYM, VMHDEB$TRACE_FREE_VM (Weak Reference)
%ILINK-I-UDFSYM, VMHDEB$TRACE_FREE_VMLIST (Weak Reference)
%ILINK-I-UDFSYM, VMHDEB$TRACE_GET_VM (Weak Reference)
%ILINK-I-UDFSYM, VMHDEB$TRACE_RET_VMH (Weak Reference)
%ILINK-I-UDFSYM, VMHDEB$TRACK_FREE_VM (Weak Reference)
%ILINK-I-UDFSYM, VMHDEB$TRACK_GET_VM (Weak Reference)
%ILINK-W-USEUNDEF, undefined symbol TEST_ADR_ECRIT referenced
section: .text
offset: %X0000000000009250 slot: 2
module: PSF_SCAT_COMMON_TOOLS
file: DISK$GIT:[users.cedric_git.mantis.build.obj]psf_scat_common_tools.OBJ;1
%ILINK-W-USEUNDEF, undefined symbol TEST_ADR_LECT referenced
section: .text
offset: %X0000000000009260 slot: 2
module: PSF_SCAT_COMMON_TOOLS
file: DISK$GIT:[users.cedric_git.mantis.build.obj]psf_scat_common_tools.OBJ;1
%ILINK-W-USEUNDEF, undefined symbol TEST_ADR_LONG referenced
section: .text
offset: %X0000000000009270 slot: 2
module: PSF_SCAT_COMMON_TOOLS
file: DISK$GIT:[users.cedric_git.mantis.build.obj]psf_scat_common_tools.OBJ;1
%ILINK-W-USEUNDEF, undefined symbol TEST_ADR_LONG referenced
section: $CODE$
offset: %X0000000000000780 slot: 2
module: CMN_TRACE_DUMP
file: DISK$GIT:[users.cedric_git.mantis.build.obj]pioche.olb;1
%ILINK-W-USEUNDEF, undefined symbol TEST_ADR_LONG referenced
section: $CODE$
offset: %X00000000000007A0 slot: 2
module: CMN_TRACE_DUMP
file: DISK$GIT:[users.cedric_git.mantis.build.obj]pioche.olb;1
$
$dir *.exe/d
PSF_SCAT_COMMON_TOOLS.EXE;17
28-SEP-2020 13:43:46.78

Cédric

Post Reply