Contents

1. Introduction
2. About Sun WorkShop 6 update 2 ILD
3. New Features
4. Software Corrections
5. Problems and Workarounds
6. Limitations and Incompatibilities
7. Documentation Errata

 

---

A. Introduction

This document contains last-minute information about Sun WorkShop 6 update 2 Incremental Link Editor, ild. This document describes the software corrections addressed by this release and lists known problems, limitations, and incompatibilities.

You cannot invoke the incremental link editor by typing the ild command at a shell prompt. ild is designed to be invoked by a compiler.

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.

For installation-related and late-breaking information about this release, see the Sun WorkShop 6 update 2 Release Notes. Information in the release notes overrides information in all readme files.

To access the release notes and the full Forte[tm] Developer/Sun WorkShop[tm] documentation set, point your Netscape[tm] Communicator 4.0 or compatible browser to the documentation index (file:/opt/SUNWspro/docs/index.html).

To access the HTML version of this readme, do one of the following:

• Choose Help > Readme from the Sun WorkShop main window.
• Point your Netscape Communicator 4.0 or compatible browser to file:/opt/SUNWspro/docs/index.html.

To view the text version of this readme, type the following at a command prompt:

   example% more /opt/SUNWspro/READMEs/ild

Note - If your Sun WorkShop software is not installed in the /opt directory, ask your system administrator for the equivalent path on your system.

Note -  In this document the term "IA" refers to the Intel 32-bit processor architecture, which includes the Pentium, Pentium Pro, Pentium II, Pentium II Xeon, Celeron, Pentium III, and Pentium III Xeon processors and compatible microprocessor chips made by AMD and Cyrix.

 

---

B. About Sun WorkShop 6 update 2 ILD

The Sun WorkShop 6 update 2 ILD runs on SPARC[tm] processors running Solaris[tm] SPARC Platform Edition, and Intel processors running Solaris Intel Platform Edition, versions 2.6, 7, and 8. Information unique to one or more platforms is identified as "(SPARC)" or "(IA)."

 

---

C. New Features

This section describes the new and changed features for the Sun WorkShop 6 update 2 ILD. In addition, it lists the new features that were introduced in Sun WorkShop 6 and Sun WorkShop 6 update.

1. New Features for Sun WorkShop 6 update 2
2. New Features for Sun WorkShop 6 update 1
3. New Features for Sun WorkShop 6
4. New Features for Sun WorkShop 5.0

1. New Features for Sun WorkShop 6 update 2

   There is no new information at this time.

2. New Features for Sun WorkShop 6 update 1

   Sun WorkShop 6 update 1 ILD included the following new and changed features.

   • Support for COMDAT

     COMDAT allows symbols to be defined in multiple modules. The first module on a command line that defines a specific COMDAT symbol is selected as the defining module. A COMDAT symbol with the same name, encountered in a module later on the command line, will be ignored.

     On a relink, if the defining module of a COMDAT symbol has been changed and no longer defines the COMDAT symbol, and if no module on the command line previous to the defining module is modified to supply the COMDAT symbol, then a FULL LINK must be done.

     See the Solaris 7 "Linker and Libraries Guide" for details about COMDAT.

   • Partially Initialized Symbols

     With Solaris 7, LD(1) accepts a construct with which it can partially initialize a symbol. Partial initialization means that very large sparse matrices can be initialized at runtime rather than allocating a large area in the a.out file for the symbol during the link phase.

     Compilers use this facility, linkers, and the runtime linker (RTLD) to specifying how arrays are initialized without actually initializing them in the a.out file. The action can result in significant savings in the size of the a.out file.

     Several notes should be made when considering this capability:

     • It can only be used for dynamically linked executables since it is RTLD that does the initializations so that the program can use the data.
     • While there may be a savings in execution time for the compilers and the linkers, there is added cost during the startup of the a.out executable since RTLD must initialize the symbol.  The benefits depend on the symbol and how populated it is with data.
     
     

3. New Features for Sun WorkShop 6

   There were no new features to describe in this release.

4. New Features for Sun WorkShop 5.0

   Sun WorkShop 5.0 ILD included the following new and changed features.

   • Support for building the following:
     
     • 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.
     
     

   • 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 is 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.

   • -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.

   • $ORIGIN token correctly passed to Runtime linker.

     See the Solaris 7 Linker and Libraries Guide AnswerBook for details.

   • 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.

 

---

D. Software Corrections

Reported bugs fixed in WorkShop 6:

• 4196586 V9: regression: __exdbg_notify_of_throw provides null catch_description - .ex_shared and .exception_ranges corruption
• 4199709 ild: Fatal error -- signal 11. Exiting. ps_call_ild() overwrite of buffer newname by 1 byte (\0 forgotten).
• 4200410 full relink if change any input file containing a scratch register symbol -SPARC
• 4205569 ILD problem on V9 relink, file too big when plenty of room (related 4204595)
• 4221151 ild: Fatal error -- Assertion failed: file "../src/ild-symtab.c" line 102[24] { COMDAT capability missing }
• 4230791 Partially Initialized Symbols AKA Partially Initialized Common Blocks
• 4255617 DT_SPARC_REGISTER has invalid value associated with it. - LD bug#4254171
• 4263566 Occasionally ILD doesn't supply _START_ and _END_ : c++
• 4265346 ILD overwrites read-only file

Reported bugs fixed in WorkShop 6 update 1:

• 4345304 Linking static lib gives ild: (bad file) garbled symbol table in archive
• 4336583 ILD -z { allextract | defaultextract | weakextract } causes failures in link
• 4334800 ild -xsb broken for TAZ : sbfocus not found if PATH not set
• 4334753 ILD should skip .so and elements of .a files not for target architecture
• 4330119 SIGPIPE occasionally slips to cc driver when ild missing sbfocus
• 4291938 archive object named *.lib on cmd line : EL_UNINITIALIZED
• 1164358 ild drops some empty elf sections

Reported bugs fixed in WorkShop 6 update 2:

• 4397939 v9 build with -xcode=abs44 causes segmentation violation in a.out

  Building an executable with the v9 instruction set and with -xcode=abs44 causes a segmentation violation in a.out.

  The relocation R_SPARC_M44 was being incorrectly processed, so that 0x3ff would be the value used rather than a mask to get the value.

  The following assembly code sequence shows typical result from this relocation:

  sethi   %hi(0x100000), %l0
  or      %l0, 0x3ff, %l0 ! 0x1003ff
  st      %l0, [%l1 + 800]
  

  The mask is used as the value. A more reasonable sequence follows:

  sethi    %hi(0x100000), %l0
  or       %l0, 0x48, %l0 ! 0x100048
  st       %l0, [%l1 + 800
  

  For each example, 3 relocations are used in V9, R_SPARC_H44, R_SPARC_M44, R_SPARC_L44.

  R_SPARC_M44 incorrect processing has been present since the first V9 ILD code.

• 1260817 identical DT_NEEDED entries not detected by ild

  ILD does not register a conflict if a shared object is given an internal name that conflicts with another library name.

 

---

E. Problems and Workarounds

This section discusses the following software bugs that could not be fixed in time for this release. For updates, check the Forte Developer Hot News web page (http://www.sun.com/forte/developer/hotnews.html).

• C++ COMDAT

  C++ will be have an option to use COMDAT for template instantiations. C++ will be using extensions to the original RFE for COMDAT that are supported by ld(1), but not by ild(1). For this reason, when the compiler uses the COMDAT template-instantiation option, it must not call ild as its linker.

• 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 perform 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, exercise care to obtain the full benefits of ild when ld is used with programs not compiled with -g

• ild uses the time stamp 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 can silently produce an incorrect program.

• The -m option produces a memory map, but it does not produce a listing of the nonfatal multiply-defined symbols on the standard output.

• 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 following scenarios can cause problems:

  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 <stdio.h>
  extern void myfunc1(void);
  
  int main(void)
  {
         (void)printf("Calling myfunc1\n"); myfunc1();
         return 0;
  }
  
  % cat main2.c
  #include <stdio.h>
  
  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 <stdio.h>
  
  void myfunc1(void)
  {
         (void)printf("myfunc1 called!\n");
  }
  
  % cat two.c
  #include <stdio.h>
  
  void myfunc2(void)
  {
         (void)printf("myfunc2 called!\n");
  }
  

 

---

F. Limitations and Incompatibilities 

There is no new information at this time. 

 

---

G. Documentation Errata 

There is no new information at this time. 

 

---

Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303, U.S.A. All rights reserved. 

Sun, Sun Microsystems, the Sun logo, docs.sun.com, and Solaris are trademarks, registered trademarks, or service marks of Sun Microsystems, Inc. in the U.S. and other countries.