目次

1. はじめに
2. Sun ONE Studio 8 インクリメンタルリンカーについて
3. 新規および変更された機能
4. ソフトウェアの修正事項
5. 問題点と回避策
6. 制限事項と互換性の問題
7. 記述の誤りの訂正

 

---

A. はじめに

この文書では、Sun Open Net Environment (Sun ONE) Studio 8, Compiler Collection インクリメンタルリンカー (ILD) に関する情報を提供します。 また、この文書では今回のリリースで提供される新機能やソフトウェアの修正事項について解説するとともに、既知の問題や制限事項、および互換性の問題について説明しています。この文書の記載内容はこのリリースのマニュアルの記載内容に優先します。

製品マニュアル

• リリースノート: http://docs.sun.com/ で入手できます。 リリースノートの情報は、各製品の「Readme」ファイルの情報に優先します。
• Compiler Collection のマニュアル: 製品のマニュアルページ、HTML 版の Readme、およびマニュアルは、/opt/SUNWspro/docs/ja/index.html からアクセスできます。
• Compiler Collection 開発者向けリソースポータル: 技術解説、Compiler Collection 関連のドキュメント、知識ベースなどについては、 Compiler Collection Developer Resources Portal (英語) を参照してください。

注 - Compiler Collection ソフトウェアがデフォルトの /opt 以外のディレクトリにインストールされている場合は、システム上の対応するパスをシステム管理者に確認してください。

この文書のテキスト版を表示するには、コマンドプロンプトで次のコマンドを入力します。

   more /opt/SUNWspro/READMEs/ja/ild

この文書の HTML 版を表示するには、次のファイルにアクセスします。

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

注 -  この文書では、Pentium、Pentium Pro、Pentium II、Pentium II Xeon、Celeron、Pentium III、Pentium III Xeon プロセッサおよび、これらと互換性のある AMD および Cyrix 製のマイクロプロセッサチップを含む、Intel 32 ビットプロセッサアーキテクチャを総称して Intel アーキテクチャ (IA) と呼んでいます。

 

---

B. Sun ONE Studio 8 インクリメンタルリンカーについて

このリリースの ILD は、Solaris[tm] オペレーティング環境 (SPARC (R); プラットフォーム版) と Solaris オペレーティング環境 (x86 プラットフォーム版) のバージョン 7、8、および 9 で動作します。

 

---

C. 新規および変更された機能

ここでは、このリリースの ILD で新たに追加された機能と変更された機能を説明しています。Sun ONE Studio のその他のコンポーネントについては、『Sun ONE Studio 8 の新機能』を参照してください。 ローカルシステムまたはネットワーク上でこのマニュアルをアクセスするには、file:/opt/SUNWspro/docs/ja/index.htmlを開いてください。 http://docs.sun.com にも同じマニュアルが掲載されています。

• ILD は、リンカースコープをサポートします。このサポートは、『C ユーザーズガイド』と『C++ ユーザーズガイド』で説明しているように特殊な宣言指定子を使用するか、あるいは -xldscope コンパイラオプションで有効にします。



• ILD は、ソースブラウザ情報を DWARF 形式でサポートします。このサポートは、.stab.sbfocus セクションと .stab.sbfocusstr セクションを出力実行可能ファイルにリンクすることによって有効にします。
  DWARF 形式の詳細は、『C ユーザーズガイド』または cc(1) の -xdebugformat を参照してください。



• ILD は、SPARC プラットフォーム用に改良された ILD 変数を通してスレッドローカルストレージをサポートします。
  スレッドローカルストレージの詳細は、『C ユーザーズガイド』および『C++ ユーザーズガイド』の宣言指定子に関する説明や、-xthreadvar コンパイラオプションの説明などを参照してください。

 

---

D. ソフトウェアの修正事項

ここでは、次のソフトウェアの修正事項について説明します。

• 4783169
  ILD は、入力ファイルの更新、リンク、および 2 度目の更新がすべて同時に起きるという状況を避けるように更新されました。このような状況が起きると、st_mtime が変更されないままとなり、ILD は入力ファイルの 2 度目の更新の検出に失敗します。



• 4754134
  ILD は、.stab.index%* セクションの N_OBJ スタブの数について不正な前提 (不正な comdat スタブを引き起こす) を下さないように更新されました。



• 4695562
  ILD は、割り当て不可能なセクションシンボルの再配置を確実に行えるように更新されました。

 

---

E. 問題点と回避策

ここでは、既知のソフトウェアの問題点と、それらの回避策について説明します。更新情報については、アップデート情報のページ http://sun.co.jp/software/sundev/suncc/hotnews.html を参照してください。

• ILD は現在、レジスタシンボル定義に対して追加のみのポリシーをサポートしています。このポリシーは、入力ファイルにレジスタシンボルが使用されていて、そのファイルが変更された場合は、ILD がフルリンクを実行することを意味します。



• -g 以外の最適化レベルでコンパイルすると、レジスタシンボルが使用されることがあります。このため、-g でコンパイルしなかったプログラムでリンカーが使用された場合、ILD のメリットをすべて得られるよう注意が必要です。



• ILD は、アーカイブライブラリの入力ファイルのタイムスタンプに基づいて、更新されたファイルを特定します。同じシンボルについて複数の定義がライブラリに存在しない場合、ILD は正しく動作します。ただし、1 つまたは複数のライブラリに同一シンボルの複数の定義が存在する場合、ILD に混乱が生じることがあります。このような場合、ILD は、何もメッセージを出さずに、不正なプログラムを生成することがあります。



• -m オプションは標準出力にメモリーマップを生成しますが、致命的エラーにはならない重複回定義されているシンボルのリストが生成されません。



• アーカイブファイルから入力ファイルを抽出して、インクリメンタル実行可能ファイルにリンクすると、その入力ファイルへの参照がすべて削除されても、次に初期リンクを実行するまで、入力ファイルが実行可能ファイル内に残ったままになります。次の例では、1 度目のリンクでは myfunc1 と myfunc2 を参照しています。one.o と two.o はアーカイブから正しく抽出されます。このセクション末のコード例を参照してください。
  
  

  % 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
  

  
  
  2 回目のリンクでは、myfunc2 は参照されず、実行可能ファイル内 (および two.o で定義されているその他のすべてのシンボル) に残っています。ここでa.out を削除すると、強制的に初期リンクが実行され、3 回目のリンクに示されているように、myfunc2 がなくなります。
  
  

  % cp main1.o main.o          # myfunc2 は参照されていない
  % cc -xildon main.o libfoo.a # 2 番目のリンク (増分リンク)
  % ./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
  
  
  # a.out を削除すると問題が解決する
  
   % rm a.out                     # 新しい初期リンクを強行設定
  % cc -xildon main.o libfoo.a   # 3 番目のリンク (初期リンク)
  % nm a.out | grep myfunc
  [58]    |    68832|      32|FUNC |GLOB|0    |8     |myfunc1
  

  
  
  このような問題が発生する可能性があるケースを説明します。
  
  two.o で定義しているいくつかのシンボルが、プログラム内の別の場所でも定義されている状態で two.o を取り込むと、不正な定義または重複定義シンボルエラーになります。
  
  a.out を検査する dbx などのツールは、two.o が含まれていることを検出します。たとえば、2 回目のリンクで生成されたファイルに対して dbx を実行すると、myfunc2 内での停止を要求することができます。これは重大な問題ではありませんが、混乱を招く可能性があります。
  
  階層式のエラーが発生することもあります。すなわち、アーカイブライブラリのその他の入力ファイル内にあるシンボルへの唯一の参照が、two.o に含まれていることがあります。この場合は、不必要に多くの入力ファイルが抽出されることになります。こうした新しいアーカイブライブラリでも、上記のいずれかの問題が発生する可能性があります。
  
  プログラムコード例:
  
  

  % 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. 制限事項と互換性の問題

現時点では新しい情報はありません。

 

---

G. 記述の誤りの訂正 

現時点では新しい情報はありません。

 

---

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