0

これは、私が今まで見た中で最大の単一の実行可能コードであるという点で間違いなく重要です。

ここに画像の説明を入力

これで、この全体をここで私の Mac に構築するのが少し簡単になりました (私は Linux でも LLDB を構築しようとしており、現在、そこで Python へのリンクと戦っています)。これには感謝していますが、この驚くほど大きな実行可能ファイルは、自分自身を推測しています... 何か間違ったことをしましたか? この巨大なアーカイブの中身は何ですか?

私はこれを実行しました：

% otool -TV liblldb-core.a

1159 行の出力が生成され、約 350 以上のオブジェクト ファイルが作成されます。その通りですね。私は、XCode プロジェクトが約 350 のソース ファイルを処理しているのを見ました。

私の質問は、なぜLLDBがこのように機能するのか、なぜもう少し軽量ではないのか、そしてなぜLLVMとClangコードにリンクするだけでなく、これが何であるかをしないのかということだと思います. または、このアーカイブの内容はすでにすべて LLDB 固有のコードですか? デバッガーを構築するのは大変な作業であることは認識していますが、これは正直、気が遠くなるような作業です。

-O3実行可能ファイルのサイズが肥大化する可能性が高いことを認識しています。ただし、戻ってこの怪物を再コンパイルするつもりはありません (コンピューターは smcFanControl でほとんど溶けてしまい、CPU コアの温度が摂氏 106 度に達したと報告されました)。

更新：ここで行ったさらなる学習を記録したようなものです...私はまだ巨大なliblldb-core.aまたは内部の種類のものを見つけることができず、XCode.app方法についてまだ少し混乱していますこのすべてが機能します。

4

2 に答える 2

1

Debug ビルド ディレクトリ内で最初のスクリーンショットを撮ったことに気付くはずでした。これは、使用したビルド構成が原因である可能性があることを示しています。

編集：いいえ、それは完全な答えではありません。Release ディレクトリには、実際にはliblldb-core.a、他のディレクトリよりもわずかに大きい が含まれています。

この巨大な 700MB のアーカイブは、ある種の「副作用」ファイルのようです。プロジェクトをアーカイブすると、369MB の.xarchiveファイルが作成されました。これは、ここでの「コンテンツ」のより良い表現であると確信しています。私はまだ基​​本的に、暗闇の中でつまずいてこのことを学んでいます...

更新：

ああ、わかりました、この状況を見ると、もう少し理にかなっています。

ここに画像の説明を入力

これらのファイルを Xcode でビルドした後、Release ディレクトリから取り出しました (そして-O3、Release に使用するために最小限の調整を行いました)。ここで、dSYMデバッグ情報を含む約 350MB のファイルが.xarchive以前の容量の大部分を占めていることがわかります。実際には、lldb実行可能コードの合計サイズは 40MB 未満であり、その大部分はそのフレームワーク内の実行可能ファイルとして存在します。LLDB.

これは私にとってはるかに合理的です。Xcode から Documents ディレクトリに移動したので、知らないうちに外部プログラムによって削除または変更されることはないと確信できるので、ここから/usr/lib/lldb.

于 2013-07-04T00:39:38.407 に答える
1

の本当の問題はデバッグ情報ですliblldb-core.a。750MB のうち約 720MB が DWARF です。(これを自分でテストできます。ar x liblldb-core.aディレクトリに入れるstrip -S *.oと、約 32MB の.oファイルができます。) 実際の型の一意化を行わない DWARF は、C++ プログラムで厄介な肥大化を引き起こします。

.tar.gz(削除された) LLDB フレームワークと lldb ドライバー プログラムを作成すると、その圧縮で約 10MB 程度になります。これは、lldb に必要なすべての llvm および clang ビットをリンクした後です。途中のステップがクレイジーに見えるかもしれませんが、ここでは特に法外なことは何もありません。

于 2013-07-04T07:58:55.680 に答える