Linux debugger bits: State of LLDB on Linux
先週、ゲーム開発ツールを開発しているRAD Game Toolsが、LLDBをGNU/Linux用に開発するために人を募集していた。この求人に対して、「LLDBはもう出来上がってるじゃん。今さら何すんだよ。ちょこちょことバグ直したりお手軽に使えるようにしたりするセコい商売でもするのか？」という意見が多かったらしく、RAD Game ToolsのJeff Robertsが反論している。
[Phoronix] RAD Game Tools To Take On Linux Debuggers
もう同じ質問が何度か上がっている。だいたいこういうのだ。「なんでRadとValveはLinux向けのLLDBを開発してるんだよ。もう出来上がってるじゃん？」。中には憤りを覚えたものもいるらしい。
ロバーツの野郎は「もっと詳しく言うと、RADはデバッガーを書く開発者を募集している。弊社は今、Linux向けのlldbを開発している」とかtweetしてる。
マジで？ 開発はほとんどAppleがやってるじゃん。RADは適当に乗っかって過剰広告でもするんだろうな。奴らがするのは小さなテストとかバグトラッキングとかで、LLDBがLinuxでぶっ壊れないようにすることだろうよ。LLDBはもう一年はLinuxで動いてる。
インターネットでゴングショー[訳注：芸をやらせて詰まらなければゴングを鳴らして即退場という形式のテレビ番組、ゴングショーにちなんだ言葉]が出来ればいいのになぁ。
ここ最近、優秀な人間が相当に開発して、Linux LLDBはだいぶ進歩した。Intelの4人の開発者や、AppleやFreeBSDやその他の何人かだ。だが、まだLLDBでL4D2やTF2をデバッグできるようになるには、多大な作業が必要だ。そもそも、LLDB自体をデバッグするとか、それどころか32bit版のprintf("talking out our asses!");をデバッグすることすらできていない。
数カ月前、我々が開発を始めた時には、まだLLDBは現在実行中のLinuxプロセスを列挙したり、プロセス名によってアタッチしたりできなかった。スレッドやらシンボルの分割といった主要な機能は、ごく最近追加された。一ヶ月前までは、まだマルチスレッドアプリケーションをデバッグできなかったし、シンボルやソース付きのシステムライブラリにステップインすることもできなかった。
現状で、まだコアファイルをロードすることはできないし、32bit Linuxアプリケーションのデバッグは基本まともにうごかない。i386テスト集には今日とりかかりはじめたところなのだ。
DWQRF4シンボル(gcc 4.8のデフォルト)は動かない。
Expressionは怪しいしbacktraceを使うには愛が必要だ。
私は今、assertとかnss shared libraryをロードするとクラッシュするところに取り掛かっている（前回のブログ投稿を見よ）
テスト集のいくつかのテストは64-bit Linuxでは失敗する。
262件のうちの33件のテストは32-bit Linuxでは失敗する。
Linux LLDBはしょっちゅうハングするし、ありえないほど長いロード時間も発生する。
Linuxでリモートデバッグできない。
後はlldbバグデータベースを参照。
LLDB 3.3に関するいいブログ投稿が、最近llvm.orgにあがっていて、読むべき価値がある。
http://blog.llvm.org/2013/06/lldb-33-and-beyond.html
LLDBの良い所はたくさんあるし、コミュニティや開発も楽しい。gdbを捨ててLLDB一本で行くにはまだやるべきことがたくさんある。ここに書いてあることが面白そうに思えたら、参加して手伝ってくれ。
動機が不自由ソフトウェアの開発のためという不純なのは哀しいことだ。GNU/Linux用の不自由ソフトウェアのゲームのデバッグツールとして、LLDBにかなりの労力が注がれている。何故だろうか。GPLv3のような優れた自由を保証するライセンスではなく、不自由ソフトウェアとして組み込める弱いライセンスのためだろうか。GCCは不自由ソフトウェアで使いにくくするよう、意図的に機能毎に分離して使いづらい設計になっている。GDBのコードもそのようになっていて、汚いからだろうか。
No comments:
Post a Comment