info-vax@ucbvax.ARPA (08/06/85)
From: BRUC@MIT-MC.ARPA (Robert E. Bruccoleri)
Shareable Images, Big Programs, C and Fortran
A Saga of Confusion
by Robert E. Bruccoleri
Masschusetts General Hospital
Boston, MA 02114
I work on a large program for modeling macromolecular mechanics,
and one significant problem with developing it is the long time it takes
for making a new version. A major part of this problem is the time
needed for linking it.
With Linker Manual in hand, I set about the task of making a shareable
image of most of the code and data, so that all I would have to link would
be the main program and whatever subroutines I'd be working on at the time.
For the first crack, I just simply made a shareable image of the
whole program minus the main, and linked the shareable image after the
subroutines to be replaced. This failed to work because the common
blocks referenced in the new code were different than those in the
shareable code. Next, I generated two shareable images, one for the
data, and one for the code, with a link proceeding first with the data,
then my modified subroutines, and finally the shareable image.
This worked just fine for the code written in Fortran, but in
the case of the C code, it generated access violations for any reference
to the common blocks (i.e. extern variables located in the shareable
image). After much examination and effort, it was discovered that the C
compiler does not generate the correct object code for extern
references. In Fortran, the object code is basically TIR$C_STA_PL
followed by TIR$C_STO_PICR. In C, an extra EF is output in the previous
store immediate command, and TIR$C_STO_LD is used instead of PICR. Once
you read the description of these commands in the linker manual, you can
see immediately why the code failed with access violations.
To remedy this problem, a program, BRUCLIB:FIXCOBJ, was written
which converts the object file to use the PICR. The original goal of
speeding up the link while developing the program has been achieved.
Some Notes:
1) One approach that I tried to circumvent the program with the bad
object code was to convert all the extern's to globalref's. This
necessitated writing some macro code to equate the psects to global
symbols. This approach worked as far the code references were concerned,
but generated innumerable non-relocatable address references for the
debugger records in the C code (a problem resulting from the use
of PIDR's instead of PICR'S, I think), and also confused the debugger's
symbol handling as it was impossible to avoid Ambiguous symbol errors.
2) The UNIVERSAL=* capability is sorely missed. I wrote a TECO macro that
would take the output of a LIB/LIST/NAMES and convert it to a
set of UNIVERSAL= commands.
3) The STDIO library of C must be put in the shareable image so that
the initializations that occur at link time are performed, and also
do not generate error messages. You will note that you cannot initialize
a common block via code that is linked against a shareable image.
4) The lack of demand zero compression for shareable images is sorely missed.