                                               更新日付: 2003 年 3 月 28 日

 Sun[tm] ONE Studio 8:インクリメンタルリンカー Readme

     目次

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



     ------------------------------------------------------------------

     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.
