Incremental Link Editor (ild)
12/03/98
=============================================================================
Introduction: The Incremental Link Editor (ild) provides a valuable subset
of link editor ld capabilities useful in the software development process.
Table of Contents:
A. Introduction
B. New Features
C. Software Incompatibilities
D. Current Software Bugs
E. Documentation
____________________________________________________________________________
A. Introduction
The Incremental Link Editor (ild) allows you to complete the
development sequence (the edit, compile, link, and debug loop)
efficiently and more quickly than by using a standard linker.
____________________________________________________________________________
B. New Features
(see ild(1) man page for details)
0. Support
a.
b.
c.
for building:
32-bit executables on a 32-bit machine.
64-bit executables on a Solaris 7 kernel booted in 32-bit mode.
64-bit executables on a Solaris 7 kernel booted in 64-bit mode.
1. LD_LIBRARY_PATH_64
Introduced in Solaris 7, this environment variable is similar to
LD_LIBRARY_PATH but overrides it when searching for 64-bit dependencies.
When running Solaris 7 on a SPARC processor and linking in 32-bit mode,
LD_LIBRARY_PATH_64 is ignored. If only LD_LIBRARY_PATH is defined, it us
used
for both 32-bit and 64-bit linking. If both LD_LIBRARY_PATH and
LD_LIBRARY_PATH_64 are defined, the 32-bit linking will be done using
LD_LIBRARY_PATH and the 64-bit linking using LD_LIBRARY_PATH_64.
2. -z allextract | defaultextract | weakextract
Alter the extraction criteria of objects from any archives that follow.
By default archive members are extracted to satisfy undefined references
and to promote tentative definitions with data definitions. Weak symbol
references do not trigger extraction. Under -z allextract, all archive
members are extracted from the archive. Under -z weakextract, weak
references trigger archive extraction. -z defaultextract provides a
means
of returning to the default following use of the former extract options.
3. $ORIGIN token correctly passed to Runtime linker.
See the Solaris 7 Linker and Libraries Guide AnswerBook for details.
4. Register Symbols:
ild supports named and scratch register symbols as
defined in the SPARC V9 ABI. A new set of messages are provided to
detail any errors due to the illegal use of these symbols. Register
symbols may be added on relinks, but if an object file that already
had a register symbol definition is modified, a full link must be done.
____________________________________________________________________________
C. Software Incompatibilities
o When ild is invoked to create shared objects, ild invokes ld to do the
link.
o Do not use ild to produce the final production code for shipment. ild makes
the file larger because parts of the program have been spread out due to
padding. Because of the padding and additional time required to link, it is
recommended that you do not use the -xildon option for production code.
o ild may not link small programs much faster, and the increase in size of
the
executable is greater than that for larger programs.
o Third party tools that work on executables may have unexpected results on
ild produced binaries.
o Any program that modifies an executable, for example strip or mcs, might
affect the ability of ild to perform an incremental link. When this
happens,
ild issues a message and performs an initial link. See the section on ild
Relink Messages in the chapter on incremental linking in the Sun WorkShop
manual "Debugging a Program With dbx".
o Normally, ILD is used when the developer compiles with the -g
optimization level. At this optimization level, register symbols are
not used.
ILD currently supports an add-only policy for register symbol
definitions. This policy means that if an object (*.o file) uses
register symbols, then a modification of that file will cause ILD to do
a full link, rather than an incremental link.
Compiling with an optimization level other than -g can result in the
use of register symbols. Therefore, care should be exercised to obtain
the full benefits of ILD whLD when used with programs not compiled with
-g.
____________________________________________________________________________
D. Current Software Bugs
1. ild uses the timestamp associated with an archive library object file to
determine which files have been updated. If multiple definitions of the same
symbol do not exist in any of the libraries, ild works correctly. However,
multiple definitions of the same symbol in one or more libraries can confuse
ild. In these cases, ild may silently produce an incorrect program.
2. The -m option produces a memory map, but it does not produce a listing of
the nonfatal multiply-defined symbols on the standard output.
3. Once an object file is extracted from an archive file and linked into an
incremental executable, that object file remains in the executable, even if
all references to it are removed, until the next initial link. In the test
case shown here, the first link has a reference to myfunc1 and myfunc2. Both
one.o and two.o are correctly extracted from the archive. See code at the
end of the bug description.
% cc -c main1.c main2.c one.c two.c
% ar cr libfoo.a one.o two.o
% rm -f a.out
% cp main2.o main.o
# references myfunc1 and myfunc2
% cc -xildon main.o libfoo.a
# first link (initial link)
% ./a.out
Calling myfunc1!
myfunc1 called!
Calling myfunc2!
myfunc2 called!
% nm a.out | grep myfunc
[59]
|
68912|
32|FUNC |GLOB |0
|8
|myfunc1
[60]
|
68960|
32|FUNC |GLOB |0
|8
|myfunc2
In the second link, myfunc2 is no longer referenced but it still appears in
the
executable (as well as any other symbols defined in two.o). Then by removing
the a.out, a new initial link is forced which the third link demonstrates as
no
longer containing myfunc2.
% cp main1.o main.o
# myfunc2 no longer referenced
% cc -xildon main.o libfoo.a
# second link (incremental link)
% ./a.out
Calling myfunc1
myfunc1 called!
% nm a.out | grep myfunc
[59]
|
68912|
32|FUNC |GLOB |0
|8
|myfunc1
[60]
|
68960|
32|FUNC |GLOB |0
|8
|myfunc2
# Removing a.out fixes the
problem.
% rm a.out
# force a new initial link
% cc -xildon main.o libfoo.a
# third link (initial link)
% nm a.out | grep myfunc
[58]
|
68832|
32|FUNC |GLOB |0
|8
|myfunc1
The scenarios that can cause problems are:
Some symbols defined by two.o are defined elsewhere in the program, and
including two.o either gets the wrong definition or a multiply-defined
symbol error.
dbx and other tools that examine the a.out still detect that two.o is
included. For example, if you run dbx on the output of the second link, you
can request stop in myfunc2. This is not really a problem, but it can be
confusing.
It is possible to also have cascading errors. That is, two.o can contain the
only
reference in the program to symbols that appear in other object files of the
archive, causing more object files to be extracted unnecessarily. These new
archives can suffer from any of the problems listed above, as well.
PROGRAM CODE:
% cat main1.c
#include
extern void myfunc1(void);
int main(void)
{
(void)printf("Calling myfunc1\n"); myfunc1();
return 0;
}
% cat main2.c
#include
extern void myfunc1(void), myfunc2(void);
int main(void)
{
(void)printf("Calling myfunc1!\n"); myfunc1();
(void)printf("Calling myfunc2!\n"); myfunc2();
return 0;
}
% cat one.c
#include
void myfunc1(void)
{
(void)printf("myfunc1 called!\n");
}
% cat two.c
#include
void myfunc2(void)
{
(void)printf("myfunc2 called!\n");
}
____________________________________________________________________________
E. Documentation
See the ild(1) man page and the chapter on incremental linking in the
Sun WorkShop manual "Debugging a Program With dbx".