Contents

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

 

---

A. Introduction

This document contains information about the Forte[tm] Developer 7 Incremental Link Editor (ILD). This document describes the new features that are included with this release, software software corrections that are addressed by this release, and lists known problems, limitations, and incompatibilities. Information in this document overrides information in the manuals for this release.

You cannot invoke the ILD by typing the ild command at a shell prompt. The ILD is designed to be invoked by a compiler.

Information in the release notes overrides information in all readme files. To access the release notes and the complete Forte Developer documentation set, go to the documentation index at file:/opt/SUNWspro/docs/index.html.

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, go to:

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

Note - If your Forte Developer 7 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 the Incremental Link Editor

This release of the ILD is available on the Solaris[tm] operating environment (SPARC[tm] Platform Edition) and Solaris operating environment (Intel Platform Edition) versions 7, 8, and 9.

 

---

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. For information about other Forte Developer components, see the What's New manual. To access this manual on your local system or network, go to file:/opt/SUNWspro/docs/index.html. You can also access this manual by going to http://docs.sun.com.

• 4502696
  The ILD has been enhanced to handle R_SPARC_UA64 relocations.
  
  
• 4421369
  C++ can supply sections in the input file containing exception range information. These data must be associated with a text section. As long as there is only one text section and one exception-range section per input file, the linker and the ILD both handle the associations.
  
  However, if -xF is used, C++ can create multiple .text and .exception_ranges sections per input file. The ILD has been enhanced in this release to also handle such associations.



• 4421361
  In the original Request For Enhancement (RFE), only .text sections were required to be definable as comdat sections. However, with the new section header type of SHT_GROUP defined in the Generic Application Binary Interface (gABI), the ILD's definition of comdat has been extended to allow any section to be declared a comdat section.



• 4421311
  In order to correctly order some initialization code, C++ needs to start using SHN_BEFORE and SHN_AFTER. The ILD is not capable of ordering sections in this manner, since on relink, new code may need to go into padding areas.
  
  To accommodate these ordering directives, the ILD placees SHN_BEFORE sections first, then unspecified sections, followed by padding, and finally SHN_AFTER sections.
  
  Consequently, if a file that has a SHN_BEFORE or SHN_AFTER section changes on a relink, then a full link is forced. Also, if a file that does not have SHN_BEFORE or SHN_AFTER has such a section on relink, a full link is forced.
  
  Since initialization files of this type are generally not changing by the developer, this implementation should not impact the normal development cycle.



• 4421303
  The ILD needs to support SHT_GROUP section headers from gABI.
  
  C++ is using the new definition of SHT_GROUP provided in the new gABI to implement comdat. The C compiler also uses this new means of defining comdat sections.
  
  The ILD must support this definition of comdat, and therefore SHT_GROUP, if it is to be used by either of these compilers.

 

---

D. Software Corrections

• 4490302
  As required by the original comdat RFE, Sun implemented a new section type, SHT_SUNW_comdat, which defines a section as a comdat section. When this mechanism is used, special symbol table entries (stabs) processing for the comdat section is required.
  
  The termination code in dealing with a specific stabs section entry for a comdat section was not correctly initializaed and could cause a SEGV.



• 4459471
  The ILD did not properly handle relocations for non-allocatable sections. Although a non-allocatable section does not occupy runtime memory space, its information may be used by tools such as the Performance Analyzer.
  
  
• 4421337
  On relink, if an input file changes and if a section must be put into a padding area, then the location of the older version of the input file's section must be cleared. Usually the area is cleared with zeros, or at times it does not matter since the area is no longer referenced.
  
  However, in the case of the C++ exception_ranges section in the a.out file, the entire section can still be referenced, even the newly vacated areas. The ILD has padded with zeros since the introduction of the code. C++ error handling code searches the entire area using a binary search algorithm. If the handler references a vacated area, it finds the zero and can erroneously check it assuming it is a valid offset. When this incorrect assessment occurs, the handler loses its place in error handling and returns incorrect results.
  
  As the process of incremental linking continues, the situation can deteriorate.



• 4416779
  The ILD complained about two -l file arguments if they have different names but in fact are the same file. (For example, one is linked to the other.)

 

---

E. Problems and Workarounds

This section discusses known software problems and possible workarounds for those problems. For updates, check Forte Developer Hot Product News at http://www.sun.com/forte/fcc/hotnews.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 

There is no new information at this time.

 

---

G. Documentation Errors 

There is no new information at this time.

 

---

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