パスワードを忘れた? アカウント作成
8660 story

gcc-3.4に脅かされるFreeBSD5.3-RELEASE 19

ストーリー by Oliver
母たるコンパイラ 部門より

Anonymous Coward曰く、"2004年5月から6月にかけての状況報告を公開し、5.3-RELEASEへ向けてのcode freezeを8/15に予定しているFreeBSDであるが、ここにきて5.3の主要な変更項目の一つであるgcc 3.4の導入により、ブートローダが正常に動作しないという問題が報告されている。参考:BSD-annex氏の日記
gcc 3.4とブートローダというと、grubでも問題が発生し、開発者のokuji氏によってgccのbugが原因であることが判明している。ソースの読解能力のないタレコミ人には、この2つに関連があるのかどうかは判断できないが、仮に今回のFreeBSDにおける問題の主原因がコンパイラ側にある場合、遅れに遅れているFreeBSD 5.3のリリーススケジュールに多大な影響を与えることは必至だ。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • gcc3.4.0でgrubをコンパイルするとコードサイズが異常に大きくなるとの事ですが,
    grubがコンパイラのバグという地雷を踏んだ理由の一つとして
    そのソースコードの書き方にも原因があると思います.

    grubの該当するソースコードは,関数の中で関数を定義するという妙な記述をしています.
    これは,一般的なC言語の文法上はエラーになるので,めったに利用されない書き方です.gcc以外ではコンパイルさえ出来ない気がします.

    このような普段あまり利用されない記述をしているから,
    コンパイラのバグに引っかかるという見方も出来ると思います.

    さて,liloが正しくコンパイルできない原因は何なのでしょうか?
    気になるところです.
    • > grubの該当するソースコードは,関数の中で関数を定義するという妙な記述をしています.

      それはそれで問題あると思うのですが、IA32プラットフォームでそういうのをコンパイルしたとき、スタック上に実行コードを乗っけて、そこに分岐する、という野蛮な実装は他の CPU ではどういうコードに落ちるんでしょう。

      (私の思い違いでなければ)IA64では、他のまっとうな高機能 CPU と同様にテキストセグメントとデータセグメントが明確に分かれていてスタック上の番地にジャンプするなんてことはできないと思うのですが。

      もしかして gcc の IA32 への対応のしかたが悪いだけ?
      親コメント
    • さて,liloが正しくコンパイルできない原因は何なのでしょうか?
      え? lilo もダメなんですか?

      # grub も lilo もダメになるんだったら 3.4.x 系列への移行やめるかな...
      # まあ試せばすぐ分かることですが。

      親コメント
    • >このような普段あまり利用されない記述をしているから,
      >コンパイラのバグに引っかかるという見方も出来ると思います.

      そうなんでしょうか?

      世間のユーザはあまり使わないかもしれない(^^;けど、一方で、
      それをわざわざ開発した開発者諸兄は、熱心にテストするかもかも。

      #職場で、annotateを見れば見るほど、彼らを信用できなくなってくるのでG7
      親コメント
    • by Anonymous Coward on 2004年07月31日 15時31分 (#598917)
      Algol60以降のプログラミング言語は手続きを入れ子にできる仕様をもつものが多く
      て、識別子の有効範囲規則はそのために存在していました。Pascal, PL/I, Ada ...

      むしろ、C言語の仕様が手抜きではないでしょうか。手続きが入れ子にできなければ、
      実行時に静的リンク/ディスプレイが不要になるため、実行時環境の手抜きができる
      ということでしょう。

      Think Pascalで、コールバック手続きを内部手続きにしておくと、大域変数を別途
      宣言する必要がなくて、非常に便利だったのを覚えています。
      親コメント
      • by argon (3541) on 2004年07月31日 17時01分 (#598955) 日記
        > むしろ、C言語の仕様が手抜きではないでしょうか。手続きが入れ子にできなければ、
        > 実行時に静的リンク/ディスプレイが不要になるため、実行時環境の手抜きができる
        > ということでしょう。

        手続きの入れ子がなくても、C の機能に限定しても、ソース分割で充分な気がします。
        今日ではクラスによる分離、名前空間の方が有効だと思います。

        実際に、分割コンパイルができる Turbo Pascal では、入れ子が深くなって
        読みにくくなるのを避けるため、分割単位でのローカルな手続きを使っていました。
        大域変数も、分割単位のスコープのローカル変数に閉じ込められました。

        gcc の nest function は、GNU Pascal の副産物のように聞いていますが、
        地雷には違いないようですね。
        親コメント
      • 実行時に静的リンク/ディスプレイが不要になるため、実行時環境の手抜きができるということでしょう。

        実行時環境とは何の関係もありませーん。スタティックリンクを含めたアクティベーションレコードやディスプレイをセットアップするのはコンパイラのお仕事です(スタティックリンクを含めてアクティベーションレコードをきちんとセットするようなコードを生成する訳ですから)。つまり、Cはコン

    • となるとokui氏の指摘が微妙になるよなあ。
      grubのソースを弄れば問題ないのか、特殊な関数定義をしなきゃいけない理由があるのか。
      確かGentooは既に~x86で3.4に移行している人がいるはずなんだが
      grubがどうこうという話は聞かないし。

      エロい人もっと詳細求む。
  • なおりました (スコア:2, 参考になる)

    by Anonymous Coward on 2004年07月31日 10時48分 (#598754)
    • by hetareDAIO (17407) on 2004年07月31日 11時19分 (#598781) 日記

      ふーむ、特殊なコンパイルオプションをつけて対処ですか。

      件のソースに興味が出てきたのでID。

      --
      ほえほえ
      親コメント
    • Re:なおりました (スコア:1, 参考になる)

      by Anonymous Coward on 2004年08月02日 15時47分 (#599949)
      GCC 3.4になって、ソースファイルを全部読んでから、コード生成を始めるのがデフォルトになったんですが、その影響が出てしまったようですね。関数の配置が変わってアウトだったんでしょうか。
      親コメント
typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...