6. バグレポート

読者からのバグレポートは, ld の信頼性を高める上で 本質的な役割を担っている.

バグを報告することは, 読者のところの問題の解決の助けになるかもしれないし, あるいはならないかもしれない. だが, どんな場合でも, バグレポートの 一番の目的は, ld の時期バージョンを改善することで, コミュニティ 全体を助けることにある. バグレポートは, ld を保守する上で 読者の貢献となるのである.

バグレポートがその目的を果たすようにするためには, 我々がそのバグを 修正可能にする情報を入れて貰わなければならない.

6.1 これはバグだろうか?
6.2 バグレポートの方法

6.1 これはバグだろうか?

バグをみつけたかどうか自信がないときのために, 以下にいくつか指針をあげる.

• GNU リンカが致命的なシグナルを受けとったなら, 入力がどんなものであっても, それは ld のバグである. 信頼のおけるリンカなら落ちたりしない はずである.

• 正しい入力でエラーメッセージが出たなら, それはバグである.

• 正しくない入力に対してエラーメッセージを出さなかったら, それは バグの可能性がある. 一般に, GNU リンカはオブジェクトファイルが 正しいかどうか検証するのは不可能である.

• 色々なリンカについて経験を積んでいるユーザなら, 改良案は いつでも歓迎である.

6.2 バグレポートの方法

多くの企業や個人が GNU の製品に対するサポートを行なっている. サポートを行なっている組織から ld を入手した場合は, まずその組織に問い合わせることをお勧めする.

サポートを行なっている企業や個人の問い合わせ先は, GNU Emacs の配布の中の `etc/SERVICE' というファイルに たくさん載っている.

さもなければ, ld についてのバグレポートを `bug-binutils@gnu.org' 宛に送って欲しい.

役に立つバグレポートを行なうのに一番重要な点は次の通り. 事実を全て報告すること. 事実かどうか書くのに迷ったなら, 書くこと!

よく事実を省略する人がいる. 何が問題を起こしているのか分かっているし, 詳細は関係ないだろうと考えるからである. そうして, 問題の起きる例で 使っているシンボル名は関係ないと考えてしまう. おそらく関係ないかも しれないが, 確認はできない. おそらく, そのバグはメモリ参照が変なところを 指しているものであり, その名前がメモリ中に格納されている位置から 取り出した時に発生するものかもしれない. おそらく, その名前が違っていれば, その位置の内容が, バグがあるにも関わらず正しい動作になるようにリンカを 誤魔化すかもしれないのである. 安全側に立って, 詳細で完全な例を 送るようにして欲しい. それが読者にとっては一番簡単なことであり, 一番役に立つことなのである.

バグレポートの目的は, 新規のバグを修正することができるようにするものだという ことを忘れないで欲しい. そのため, バグレポートをするときは, 常に, そのバグは以前に報告されたことがないという前提で行なって欲しい.

時々, 不完全な事実を少しだけ伝えて, 「これ当たった?」と聞く人がいる. こういうバグレポートは役に立たないし, 我々としては, 報告者に 正しいバグレポートを送るように注意する以外は, 誰も反応しないように して欲しい.

我々がバグを直せるように, 以下の項目を全て必ず入れてほしい.

• ld のバージョン. 引数 `--version' を指定すると ld はバージョンを表示します.

  そうしないと, 現在のバージョンの ld にバグを探すべき点が あるのかどうか分からないからである.

• ld のソースに当てたパッチがあればそのパッチ. これには BFD ライブラリ用のパッチも含む.

• 使用している機種や, OS 名とそのバージョン番号.

• ld をコンパイルするのに使ったコンパイラとそのバージョン. 例えば, "gcc-2.7".

• 読者が例をリンクするのに使い, バグを観察したとき, リンカに指定した コマンド行引数. 何か重要なものを漏らさないように, 全てを書いて欲しい. Makefile(あるいは make の出力)があれば, それで充分である.

  もし我々が引数を推測するはめになったら, 多分推測を間違って, バグを再現できないことになるだろう.

• バグを生成する, 一つの, あるいは複数の完全な入力ファイル. 一般には実際のオブジェクトファイルを送って貰うのが一番役に立つ. その場合, オブジェクトファイルはメールシステム経由で送れるように uuencode する. 匿名 FTP で入手できるようにするのはあまり良くないが, オブジェクトファイルが大きい場合には適切な選択肢としては 唯一のものになる.

  ソースファイルを gas でアセンブルしたり, gcc で コンパイルした場合には, オブジェクトファイルではなく, ソースファイルを 送るのでも良いことがある. その場合には, オブジェクトファイルを 生成するのに使った gas や gcc の正確なバージョンを 知らせて欲しい. また, gas や gcc のコンフィギュレーション の方法も書いて欲しい.

• 読者が正しくないと思うことについて, 読者が見たものについての説明. 例えば, 「致命的シグナルを受けとった」などである.

  そのバグが致命的シグナルを受けるというものなら, 当然ながら, 確実に 気がつくだろう. だが, 出力が間違っているというものだったとすると, とんでもなく目立つ間違いでない限り, 気がつかない可能性がある. 同様に間違いを犯す機会を与えてくれない可能性もあるのである.

  たとえ読者の出会った問題が致命的シグナルであっても, それを はっきりと伝えて欲しい. 何か変なことが起きているとしよう. 例えば, 読者のところの ld が 古いとか, あるいはシステムの C ライブラリのバグに遭遇したとしよう. (これは 実際にあったことである. ) 読者のところでは落ちるかもしれないが, 我々のは落ちないのである. 落ちることが予想されることを教えてくれれば, 我々のが落ちなかった時, 我々にはバグが発生しなかったということが分かる. 落ちるはずであると 言ってくれなければ, 観察したことから何の結論も引き出せないのである.

• ld のソースに対する変更を提案する場合は, コンテキスト差分で 送って欲しい. コンテキスト差分は diff コマンドに `-u' か `-c' か `-p' オプションを指定すると得られる. 必ず, 古いファイルから新しいファイルへの差分として送って欲しい. ld のソースについて何か話をする場合は, 行番号ではなく, コンテキストで場所を指し示すようにして欲しい.

  我々の開発ソースでの行番号は読者のところのソースの行番号とは 一致しない. 読者の行番号は我々に役に立つ情報を何ももたらさないのである.

以下に必要ではないものを示す.

• バグの概要についての説明.

  人はバグに出会うと良く, 入力ファイルをどう変えるとバグがなくなり, どう変えるとなくならないかということを調べるのに時間を費やすことが あるようだ.

  これはあまり役にたたずに時間の無駄使いに終ることが多い. というのは我々のバグの見つけ方は, 一個の例をデバッガのもとで ブレークポイントをはって実行させるというもので, 一連の例から 純粋に演繹するという方法ではないからだ. 我々としては, 何か他の ことに時間を使って欲しいと思っている.

  もちろん, 元のものよりも簡単な例を見つけて, それを代わりに報告できれば, 我々にとっては役にたつ. 出力中のエラーが見つけやすくなるし, デバッガを実行する時間も短くて済む等々.

  ただし, 単純化は必須ではない. 単純化という作業をしたくないのであれば, 何はともあれバグを報告し, 読者が使ったテストケースをそのまま送って欲しい.

• バグに対するパッチ.

  バグに対するパッチはそれが良いものであれば助けになる. ただし, テストケースのように, そのパッチが必要充分なものであることを 証明する必要な情報を忘れないで欲しい. 我々は読者のパッチに 問題があれば別の方法で問題を直すだろうし, あるいは読者のパッチが全く 理解できないということもある.

  ld ぐらい複雑なプログラムだと, プログラムがコードのある決まった 経路を通るような例を作るのが非常に困難な場合がある. 読者が例を 送ってくれないと, 我々にはそういう例を作れないだろうから, バグが直ったかどうか検証できないのである.

  そして, 読者の修正しようとしているバグが何なのか, あるいは 読者のパッチがどうして改良になっているのか分からない場合は, われわれはそのパッチをインストールしない. テストケースがあれば 理解の助けになる.

• バグがどんなものか, あるいはそれが何に依存しているかについての 推測.

  そういう推測は大体間違っている. 我々でさえ, まずデバッガを使って 事実を掴まないことには正しい推測ができないのである.