Contents

1. Introduction
2. About the Sun Studio 10, Incremental Link Editor
3. New and Changed Features
4. Software Corrections
5. Problems and Workarounds
6. Limitations and Incompatibilities
7. Documentation Errors

 

---

A. Introduction

Note: The Incremental Link Editor (ild) is a special-purpose linker that can, in limited situations, perform program linkage faster than the general-purpose system linker ld. This feature might be removed in a future release. When ild is no longer available, ld will be used automatically instead. ild is not avaialbe when you specify -xarch=amd64.

This document contains information about the Incremental Link Editor (ild) for the Sun Studio 10 release. This document describes the new features, software corrections, known problems, limitations, and incompatibilities of this release. Information in this document overrides information in the manuals for this release.

Product Documentation

• Release Notes: Available on the Sun Studio 10 web site at http://developers.sun.com/tools/cc/documentation/ss10_docs/release_notes.html . Information in the release notes updates and extends information in all readme files.
• Sun Studio 10 Documentation: Product man pages, HTML versions of readmes, and manuals can be accessed from /installation_directory/SUNWspro/docs/index.html. The default installation directory is /opt. You can access the following documents from the index.html page:
  • C Compiler Readme
  • C++ Compiler Readme
  • C User's Guide
  • C ++ User's Guide
  • Math Libraries Readme
  • Numerical Computation Guide
  • Sun Performance Library Readme
  • Sun Performance Library Reference Manual
  • Sun Performance Library User's Guide for Fortran and C
• Integrated Development Environment (IDE) Documentation: Online help for all components of the Sun Studio 10 IDE can be accessed from the Help menu in the IDE.
• Developer Resources Portal: For technical articles, code samples, documentation, and a knowledge base, see the developers portal at http://developers.sun.com/prodtech/cc.

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

   more /opt/SUNWspro/READMEs/ild

To view the HTML version of this readme, point your browser to the default installation directory:

   file:/opt/SUNWspro/docs/index.html

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

 

---

B. About the Sun Studio 10, Incremental Link Editor

This release of the ild is available on the Solaris[tm] Operating System: versions 8, 9, and 10

 

---

C. New and Changed Features

This section describes the new and changed features for the ild. These new and changed features are logged in the Bugtraq+ database under the identification number listed with each item.

• ild supports linker scoping as enabled by the special declaration specifiers documented in the C User's Guide, and the C++ User's Guide, and as enabled by the -xldscope compiler option.



• ild supports source browser information in DWARF format by linking .stab.sbfocus and .stab.sbfocusstr sections into the output executable.
  For more information on the DWARF format, see -xdebugformat in the C User's Guide or in cc(1).



• ild supports thread-local storage through enhanced ild variants for the SPARC platform.
  For more information on thread-local storage, see the declaration specifiers documented in the C User's Guide, and the C++ User's Guide, as well as the explanation for the -xthreadvar compiler option.

 

---

D. Software Corrections

This section details the following software corrections:

• 4783169
  ild has been updated to avoid the scenario in which the actions of updating an input file, linking, and second updating all happen at the same second. Such situations would make ild fail to detect the second update of the input file (as its st_mtime remains unchanged.)



• 4754134
  ild has been updated to remove an incorrect assumption on the number of N_OBJ stabs in .stab.index%* sections, which resulted in bad comdat stabs.



• 4695562
  The ild has been updated so that it can handle relocations properly for non-allocatable section symbols.

 

---

E. Problems and Workarounds

This section discusses known software problems and possible workarounds for those problems. For updates or patches, check the information at http://developers.sun.com/prodtech/cc/support_index.html.

• The ild currently supports an add-only policy for register symbol definitions. This policy means that if an input file uses register symbols, then a modification of that file causes the 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 the ild when the linker is used with programs that are not compiled with -g.



• The ild uses the time stamp associated with an archive library input file to determine which files have been updated. If multiple definitions of the same symbol do not exist in any of the libraries, the ild works correctly. However, multiple definitions of the same symbol in one or more libraries can confuse the ild. In these cases, the 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 input file is extracted from an archive file and linked into an incremental executable, that input file remains in the executable until the next initial link, even if all references to it are removed. 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 input files of the archive, causing more input 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 

This section discusses limitations and incompatibilities with systems or other software. For last-minute information about this Sun Studio 10 release, see the Sun Studio 10 Release Notes at http://developers.sun.com/tools/cc/documentation/ss10_docs/release_notes.html.

 

---

G. Documentation Errors 

There is no new information at this time.

 

---

Copyright © 2004 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.