Linux で最高の C C++ プログラミングおよびデバッグソフトウェア

ホーム» Python » Linux 上の C および C++ プログラミングソフトウェアとデバッグツール

最新の Linux C/C++ 開発では、最適化された標準準拠のバイナリを提供するために、GCC、Clang/LLVM、IBM Open XL C/C++ などのソリューションに依存しています。
Linux での効果的なデバッグでは、VS Code などのエディター統合だけに頼るのではなく、GDB、IDE フロントエンド、適切な DWARF デバッグ情報を組み合わせます。
strace、ltrace、SystemTap、コアダンプワークフローなどのツールは、システムコール、ライブラリの相互作用、事後状態を公開することで GDB を補完します。
最近の GDB および RHEL の変更により、堅牢性、スクリプト、メモリの安全性が強化され、大規模な C/C++ デバッグがより制御可能かつ予測可能になりました。

Linux 用 C および C++ プログラミングソフトウェア

WindowsとVisual Studio環境で開発していた人が、突然Linux上の巨大なCまたはC++コードベースに放り込まれると、その変化は過酷に感じられるかもしれません。VS Codeのようなエディタの背後でGDBを使って何十万行ものコードをステップ実行し、各ステップに30～60秒も待たされると、自分が何か重大な間違いを犯しているのではないか、あるいはLinux開発はそもそも設計上遅いのではないかと不安になるかもしれません。しかし朗報です。最新のLinuxツールチェーンとデバッガは非常に高性能です。必要なのは、それらをどのように設定し、どのツールが大規模なC/C++プロジェクトに適しているかを知ることだけです。

このガイドでは、Linux 上の C/C++ コンパイラ、IDE、デバッグツールの全体像を解説します（「Linux をゼロからマスターする」を参照）。GCC、Clang/LLVM、IBM Open XL C/C++ から、GDB、Eclipse、SystemTap、strace、ltrace、高度なコアダンプワークフローまでを網羅します。また、Geany + GCC のような定番の学習環境についても触れ、デバッグを高速化し、Linux での C および C++ 開発を Windows での快適な作業環境に近づけるための具体的なヒントも紹介します。

Linux 上の C および C++ コンパイラ: GCC、Clang/LLVM、IBM Open XL

Linux では、C および C++ のリファレンスツールチェーンは依然として GCC (GNU コンパイラコレクション) であり、C++ フロントエンドとして g++ が使用されています。ほとんどのディストリビューションはデフォルトでGCCを搭載しており、事実上すべてのチュートリアル、ビルドシステム、CIパイプラインはGCCの存在を前提としています。通常は次のようなコマンドでコンパイルします。 gcc Cおよび g++ 例えばC++の場合 g++ -g -O2 main.cpp -o app デバッグ可能で最適化されたバイナリを構築します。

ClangとLLVMエコシステムは、Linux上でGCCに代わる強力な選択肢へと成長し、高速コンパイル、優れた診断機能、そして豊富なツールセット（静的解析、コードフォーマット、サニタイザーなど）を提供しています。Clangは、LLVMを基盤としたC/C++フロントエンドであり、LLVMは複数のアーキテクチャと言語をサポートするモジュール型のオープンソースコンパイラインフラストラクチャで、大規模なコミュニティによって積極的にメンテナンスされています。

IBM Open XL C/C++ for Linux on Powerは、Clang/LLVMとIBMの長年にわたるコンパイラ最適化の専門知識を緊密に統合した商用ツールチェーンです。IBM Powerシステムを対象とし、最新のC/C++言語機能（C++17を含む）、標準的なLLVM最適化、およびGCCとの互換性を活用して、Powerハードウェア上で高性能なバイナリを提供します。つまり、LLVMエコシステムのメリットに加え、IBMが開発したプラットフォーム最適化の恩恵を受けることができます。

レガシー環境向けに、IBMは引き続きLinux用の旧バージョンのXL C/C++コンパイラを提供しているため、既存のビルドチェーンや認証上の制約がある組織は、新しいワークロード向けにOpen XL C/C++を段階的に導入しながら、引き続きそれらを使用することができます。

Linux 上の C および C++ コンパイラツールチェーン

古典的な学習環境: GCC と軽量 IDE

Linux上でCまたはC++を始めたばかりの場合、GCCとGeanyのような軽量IDEを組み合わせるのが非常に一般的で効果的な方法です。Geanyはクロスプラットフォーム（LinuxとWindows）で高速であり、プロジェクト管理、ビルドコマンド、簡単なデバッグといった基本的な機能を、本格的な重いIDEのようなオーバーヘッドなしに統合しています。

Linux向けの多くの長編C/C++コースでは、まさにこの組み合わせを推奨しています。コンパイラとしてGCC、開発環境としてGeanyです。こうしたチュートリアルを通して、通常は言語の基礎から学ぶことができます。GNUコンパイラとは何か、その起動方法、プログラムの構造化、条件分岐、関数、配列、文字列、ポインタ、構造体、共用体、ファイル入出力の扱い方、そして最終的にはC++における継承、演算子オーバーロード、ポリモーフィズムといったオブジェクト指向の概念までを網羅します。

IDEの選択は様々ですが、基本的なツールチェーンに関するアドバイスは概ね共通しています。可能な限り、プラットフォームを問わずGCC（またはg++）を使用することをお勧めします。Linuxではこれがデフォルト設定です。WindowsとmacOSでは、MinGW、MSYS2、WSL、Homebrewなどのツールを使ってGCCをインストールできます。これにより、システム間でワークフローを統一し、スクリプトやMakefileの共有を容易にすることができます。

IDEがビルド手順を抽象化している場合でも、それが単に呼び出しているだけであることを理解すると、 gcc or g++ 複雑なビルドやランタイムの問題をデバッグするには、舞台裏での実行が重要です。のようなオプション -g デバッグ情報、最適化レベルなど -O0, -O2 or -O3、警告や標準準拠を調整するためのフラグ（-Wall, -std=c++17など）はすべて、微妙なバグを診断するときに非常に重要になります。

Linux 上の C および C++ 向け軽量 IDE

大規模 C++ コードベースのデバッグ: VS Code からネイティブ GDB へ

Windows版Visual StudioからLinux版に移行する開発者は、多くの場合、Visual Studio CodeとGDBベースの拡張機能から始めますが、大規模なバックエンドではデバッガーでのステップ実行が非常に遅くなることにすぐに気づきます。数十万行ものコードと多数のバックエンドコンポーネントを持つ大規模なドキュメント処理システムや配信システムをデバッグする場合、各ステップで30～60秒もの遅延が発生することは珍しくありません。

この動作の遅さは、通常、GDB自体の制限ではなく、VS Codeと基盤となるデバッガー間の統合レイヤーまたは構成に起因するものです。デバッグ拡張機能の問題、ブレークポイントの同期方法、シンボル情報の読み込み方法、MI（マシンインターフェース）コマンドの変換方法など、すべてが複雑な実世界のアプリケーションにおける大幅な動作遅延の原因となる可能性があります。

VS CodeのC/C++拡張機能には、Linux上でGDBを使用したステップ実行のパフォーマンスに関する既知の長年の問題が報告されています。一部のチームにとって、これはVS Codeがエディタとしては優れているものの、大規模なC++サービスのデバッグ用フロントエンドとしては必ずしも最速の選択肢ではないことを意味します。Google Antigravity IDEやネイティブIDEなどの代替手段が存在します。パフォーマンスが重要な場合、多くのエンジニアはGDBを直接使用するか、ローカルツールチェーンとより深く統合されたネイティブIDEに切り替えるという選択肢に頼っています。

したがって、Linux 上で VS Code のデバッグセッションの各ステップに 30 秒かかる場合でも、Linux のデバッグが本質的に遅いと決めつけないでください。諦める前に、ターミナルで同じバイナリに対して GDB を直接実行して動作を比較してみる価値があります。多くの場合、GDB 内でのステップ実行は劇的に高速化されるため、これは OS やコンパイラの根本的な問題ではなく、設定や拡張機能のボトルネックを示している可能性があります。

Linux 環境の大規模な C++ 開発現場では、快適なデバッグを実現するための一般的な代替手段として、CDT (C/C++ 開発ツール) を搭載した Eclipse、CLion、Qt Creator、KDevelop など、GDB やローカルシステムとより緊密に統合されたネイティブ IDE が挙げられます。これらの環境では、言語に依存しないデバッグレイヤーのオーバーヘッドなしに、内部で GDB を使用しながら、ソースナビゲーション、ウォッチウィンドウ、豊富なブレークポイントを提供できます。

Linux 上での C および C++ コードベースのデバッグ

Linux のデバッグ情報: ELF、DWARF、debuginfo、debugsource

Linuxでは、コンパイル済みプログラムと共有ライブラリは通常ELF（Executable and Linkable Format）ファイルに格納され、関連するデバッグ情報はDWARF形式でエンコードされます。DWARFには、デバッガがマシンコードをソースファイル、行番号、関数、型、変数にマッピングするために必要なメタデータが含まれています。

ELFバイナリのDWARFセクションは次のようなツールで調べることができます。 readelf -w file、生のデバッグレコードをダンプします。 通常、DWARF を手動で読み取ることはありませんが、これによりデバッグ情報が存在するかどうかが確認され、GDB やその他のツールで「シンボルがロードされていない」タイプの問題を診断する際に非常に役立ちます。

STABSと呼ばれる古いデバッグフォーマットはまだ存在しますが、Red Hat Enterprise Linuxなどの最新のLinuxディストリビューションでは非推奨とされており、廃止されています。GCCとGDBはSTABSに対して最大限のサポートを提供していますが、エコシステム内の主要なツール（Valgrindやelfutilsなど）はSTABSと正しく連携しない可能性があるため、DWARFの使用が強く推奨されます。

デバッグデータは容量が大きくなる傾向があるため、ほとんどのディストリビューションでは、メインバイナリからデバッグ情報パッケージとデバッグソースパッケージに分離されています。デフォルトのリポジトリからインストールする実行ファイルからは、通常、ディスク容量の節約とメモリ使用量の削減のためにデバッグシンボルが削除されます。一方、対応するデバッグ情報パッケージにはDWARFデータが含まれており、必要に応じてデバッグソースパッケージには対応するソースコードが含まれます。

RHELや類似のシステムでは、コンパイル時に明示的にデバッグ情報を要求します。 -g GCC を使用して独自のプロジェクトを構築する場合。 パッケージからインストールされたシステムライブラリやサードパーティライブラリについては、関連する debuginfo (NAIST) と debugsource 特殊なデバッグリポジトリからのパッケージ。デバッグセッション中にシンボルの欠落に気付いたときに、GDB によって直接ヒントが示されることがよくあります。

Linux 上のデバッグシンボルと ELF DWARF

システムバイナリのdebuginfoのインストールと場所

システムライブラリに依存するCまたはC++プログラムをデバッグする場合、それらのライブラリにdebuginfoをインストールしておくと、バックトレースと変数検査の質が劇的に向上します。debuginfoがインストールされていない場合、共有ライブラリでは生のアドレスまたは難読化された関数名しか表示されませんが、インストールされている場合は、行単位の正確なスタックトレースとシンボル変数名が表示されます。

RHELのようなディストリビューションでは、GNUデバッガ（GDB）は、ロードされたオブジェクトのデバッグ情報が不足している場合に自動的に検出し、必要な情報をインストールするための具体的なコマンドを提案します。 debuginfo 経由でパッケージ dnf. 推奨された方法を実行するだけで dnf debuginfo-install ... コマンドを実行し、プロンプトが表示されたら確認すると、システムがセッションに必要なシンボルパッケージを取得してインストールします。

自動ヒントが利用できない場合は、次のようなツールを使用してバイナリまたはライブラリファイルを検索し、必要なデバッグ情報を手動で特定できます。 locate RPM データベースを照会します。その locate コマンドは mlocate パッケージをインストールして初期化する必要がある場合があります。パスを取得したら、どのパッケージがそのパッケージを所有しているかを確認し、対応する debuginfo バリアントをインストールできます。

たとえば、ファイルが手動でコピーされた場合や、パッケージ化せずにインプレースでビルドされた場合など、特定のバイナリをインストールしたパッケージを特定できない場合があります。このような場合には、カスタムシンボルファイルにフォールバックするか、可能であれば、バイナリを自分で再構築する必要があるかもしれません。 -g GDB が完全なデバッグデータを取得できるように有効にします。

システム内のすべてのライブラリにデバッグ情報をインストールする必要はほとんどなく、無駄になる場合があることを覚えておいてください。OS全体のデバッグパッケージを取得するのではなく、問題に最も関連性の高いモジュール、つまりアプリケーションのバイナリと、クラッシュや誤動作が発生する特定のライブラリに焦点を当ててください。

Linux での対話型デバッグに GDB を使用する

GDBは、Linux上でネイティブCおよびC++アプリケーションをデバッグするための中心的なツールであり、コマンドラインインターフェースと、Eclipse CDTなどのグラフィカルフロントエンドとの統合機能を提供します。Red Hat Enterprise Linuxでは、標準ディストリビューションにフル機能のGDBとオプションのGUIが含まれています。

プログラムを最初からデバッグするには、通常、 gdb ./program必要に応じてブレークポイントを設定し、GDB内で実行を開始します。 run あるいは、すでに実行中のプログラムにアタッチすることもできます。 gdb -p <pid> またはGDBを起動して attach コマンドとプロセス ID を一緒に指定します。

GDBがアタッチ時に特定のPIDのターゲット実行ファイルを推測できない場合は、 file コマンドを実行してデバッグに進みます。 これは、実際の実行可能パスが明らかでないカスタムランチャー、ラッパースクリプト、または複数のバイナリセットアップを扱う場合に特に便利です。

アタッチまたは起動したら、次のようなコマンドでプログラムの流れを制御します。 n （次）、 s （ステップ）、 until, finish そして単純に c （続行）、デバッガを終了しながら q 終わったら。これらの各コマンドには、関数本体にステップインするか、指定された行まで実行するか、次のブレークポイントまたは終了まで実行を再開するかに関する特定のセマンティクスがあります。

状態を理解するために、GDBは変数、コールスタック、レジスタなどを検査するための豊富なイントロスペクションコマンドを提供し、またコンテキストヘルプも提供しています。 help info および同様のコマンド。現在のソース行を表示するには list、変数を印刷する printスタックフレームを探索する backtrace フレームをナビゲートする frame, up (NAIST) と down.

GDB のブレークポイント、ウォッチポイント、条件

実際のデバッグでは、 main()代わりに、ブレークポイントを戦略的に配置して、動作が興味深いものになる場所で正確にプログラムを停止します。 標準コマンド break ファイルと行番号、または関数名でブレークポイントを設定することができ、GDB は次のヒット時に実行を一時停止します。

たとえば、次のような構文を使用して、特定のソース行にブレークポイントを設定できます。 break file.cpp:123、または関数の開始時にbreakする break my_function. ブレークポイントの位置に到達すると、GDB はプログラムを停止し、ローカル変数を検査し、コールスタックをチェックして、ステップイン、ステップオーバー、または続行するかどうかを決定できるようにします。

条件付きブレークポイントは、バグが多数の反復処理後や特定の入力値でのみ発生する場合に非常に役立ちます。CまたはC++で記述されたブール条件をブレークポイントに関連付けることで、条件が真と評価された場合にのみGDBが停止するように設定できます。これにより、不要な停止を大幅に削減し、ループや複雑なステートマシンのデバッグをはるかに効率的に行うことができます。

コードフローではなくデータの変更を監視するために、GDB はウォッチポイントを提供します。ウォッチポイントは、式 (多くの場合、変数) の読み取りまたは書き込み時にトリガーされます。次のようなコマンドで watch, rwatch （読む）または awatch (読み取り/書き込み) を使用すると、特定のフィールドが変更またはアクセスされたときに正確に実行を停止できます。これは、予期しない状態の変化を追跡する場合に特に役立ちます。

すべてのブレークポイントとウォッチポイントは、次のようなコマンドで管理します。 info breakpoints or info br、番号または場所を指定して削除することもできます。 delete 適切な引数を付けて。これにより、アクティブなブレークポイントのセットを整理して維持しやすくなり、複数のモジュールまたはセッションにわたってデバッグを行う際の混乱を防ぐことができます。

マルチスレッドおよびフォークされたプロセスのデバッグ

スレッドやフォークを多用する C および C++ プログラムをデバッグするには、GDB が実行コンテキストを追跡する方法を特に意識する必要があります。デフォルトでは、GDBは現在のスレッドを指定し、明示的に切り替えない限り、ほとんどのコマンドはそのスレッド上で動作します。 thread およびスレッド識別子。

プログラムがフォークすると、設定は set detach-on-fork GDB が子プロセスと親プロセスのどちらに従うか、また従わないプロセスをどのように処理するかを決定します。分析に親、子、またはその両方が関連しているかどうかに応じて、GDB が両方を制御するように、または一方から自動的に切り離されるように設定できます。

新しい GDB バージョンでは、スレッドの番号付け方法が進化し、互換性のために、下位スレッドごとの ID と個別のグローバルスレッド ID が導入されました。利便性変数 $_thread そしてPython APIの InferiorThread.num 下位番号ごとに番号が反映されるようになりましたが、グローバル識別子は次のように利用できます。 $_gthread (NAIST) と InferiorThread.global_numグローバル ID に基づく古いツールが引き続き機能することを保証します。

マルチスレッドデバッグにおけるシグナル処理も改善され、シグナルが常に正しいスレッドに配信されるようになりました。シグナルによってプログラムが停止した後、スレッドを変更して実行を再開しようとすると、GDBは確認を求めることができるため、意図しない誤配信を防ぎ、シグナル関連のデバッグの信頼性が向上します。

つまり、デッドロック、競合状態、あるいは予期せぬシグナルによるクラッシュを解析する際には、GDBのスレッドモデルを利用して、正確な制御のもとで適切な実行パスを追跡できるということです。ブレークポイント、ウォッチポイント、キャッチポイントと組み合わせることで、高度な並行処理を伴うC++サービスにおいても、堅牢なマルチスレッドデバッグが可能になります。

システムおよびライブラリ呼び出しのトレース: strace、ltrace、SystemTap

C言語やC++言語のプログラムが誤動作する理由を理解する最も手っ取り早い方法は、すべての行をステップ実行するのではなく、オペレーティングシステムや共有ライブラリとの相互作用を観察することです。Linuxには、strace、ltrace、SystemTap、さらには専用のキャッチポイントを介したGDB自体など、このための強力なツールがいくつか用意されています。

その strace ユーティリティはシステムコール（カーネルとのやり取りなど）をトレースします。 open, read, write, mmap, execve など、そのパラメータと戻り値も表示されます。プログラムを実行するには strace または、実行中のプロセスにPIDでアタッチし、オプションで、次のような式を使用して表示するシステムコールをフィルタリングします。 -e trace=call フォークされた子やスレッド化された子を追跡するかどうかを制御する -f.

実際のアプリケーションは膨大な数のシステムコールを発行するため、 strace シェルツールなど tee 出力をライブで表示し、分析用に保存することは共通です。これにより、コード自体からは明らかでない可能性のある、不足しているファイル、権限の問題、予期しないネットワーク動作、その他の OS レベルの問題を特定できます。

straceを補完する ltrace ユーザー空間での共有ライブラリ関数の呼び出しに焦点を当て、動的オブジェクトからのエクスポートされた関数の呼び出しと戻り値を表示します。 RHEL 8 では、ltrace が特定のシステム実行可能ファイルを追跡できないという既知の制限がありますが、ユーザーがビルドしたバイナリでは正常に機能するため、プログラムがライブラリ API をどのように使用しているかを理解するための貴重なツールになります。

SystemTap は、独自のスクリプト言語を使用してカーネルとユーザー空間の両方のイベントに対してカスタムイベントハンドラーを可能にする、より高度なトレースフレームワークです。 straceやltraceよりも使い方が複雑になる場合がありますが、スケーラビリティが高く、高度なフィルタリングと集計機能をサポートしています。便宜上、サンプルスクリプトとして strace.stp SystemTap のインフラストラクチャを使用して strace のような動作を模倣するために SystemTap が付属しています。

GDB自体は、次のようなコマンドでシステムコールやシグナルのキャッチポイントを使用してトレースに参加することができます。 catch syscall (NAIST) と catch signal. これらにより、プログラムが特定のシステムコールを実行したり、特定のシグナルを受信したりするたびにデバッガーの実行が停止されます。これは、対話型デバッグ中にきめ細かな制御が必要な場合に非常に便利です。

GDBによるコアダンプと事後デバッグ

C言語またはC++言語のアプリケーションが、対話的に再現するのが難しい形でクラッシュしたりハングアップしたりした場合、コアダンプは、その重要な瞬間のメモリと状態のスナップショットを提供します。コアダンプは、プロセス終了時のメモリ（スタック、ヒープ、マッピング）の一部の内容を含むELFファイルであり、クラッシュ発生時にGDBに接続していたかのように、後でGDBを使用して分析できます。

コアダンプを効果的に使用するには、コアダンプが実際に生成され、リソース制限や構成によってブロックされていないことを確認する必要があります。シェルの制限など ulimit -c コアファイルの作成を防ぐことができます。制限を設定すると unlimited サイズ上限は削除されますが、実稼働システムでのディスク領域の影響を確認する必要があります。

最新のRHELシステムでは、 systemd-coredump コアダンプを透過的に管理し、ジャーナルのような集中管理された場所に保存する代わりに、 core ディレクトリ間に散在するファイル。その coredumpctl このツールを使用すると、記録されたクラッシュを一覧表示し、そのメタデータを検査し、実際のコアファイルを選択したパスにエクスポートして、より詳細な分析を行うことができます。

体系的なクラッシュキャプチャワークフローを作成する場合、 sos パッケージと使用 sosreport システム構成とログを含む tarball を生成します。 エクスポートされたコアファイルとアプリケーションバイナリを組み合わせることで、別のマシンでクラッシュを分析したり、別のチームやベンダーに引き渡したりするために必要なものがすべて揃います。

応答しないプロセスに中止信号を送るか、以下のようなツールを使うことで、意図的にコアダンプをトリガーすることもできます。 gcore、プロセスの実行中にプロセスメモリをダンプします。間に gcore ダンプの場合、プロセスは短時間停止してから通常の実行を再開し、サービスを完全に終了せずに問題のある状態のオフライン分析を可能にします。

コア分析に適した実行ファイルとシンボルを見つける

コアダンプを意味のある形で分析するには、GDBはコアファイルと、それを生成した実行可能ファイル（および関連する共有ライブラリ）の両方を必要とします。これは、異なるバージョンからビルドされたバイナリが一致しない場合、誤ったバックトレースや不正確な変数レイアウトにつながる可能性があるため重要です。

のようなツール coredumpctl info キャプチャされた各コアの詳細なメタデータを表示します。これには、メイン実行可能ファイルへのパスや、バイナリを一意に識別するビルド ID が含まれます。ビルド ID は長い 16 進ハッシュのように見える場合があり、GDB を起動する前に、バイナリのローカルコピーのビルド ID と比較して、それらが同一であることを確認できます。

実行ファイルとそのライブラリがRPMパッケージから来た場合は、 sosreport パッケージデータベースを参照して、必要なバージョンを正確に取得します。場合によっては、専用のデバッグマシンに一致するパッケージを再インストールし、GDBの set sysroot リモートスタイルのデバッグ用にミラー化されたライブラリレイアウトを指すように構成します。

正しいオブジェクトを取得したら、次のようなコマンドでGDBセッションを開始します。 gdb /path/to/exe /path/to/core GDB にコアをロードさせます。 いずれかのモジュールの debuginfo が欠落している場合、GDB は、完全なシンボルの可視性を得るためにインストールする必要があるパッケージまたはシンボルファイルに関するヒントを示すメッセージを表示します。

アプリケーションのデバッグシンボルがパッケージではなく別のファイルで提供されている場合は、 symbol-file GDB 内のコマンド。 コア内のすべての共有ライブラリのデバッグ情報を取得する必要はありません。通常、独自のアプリケーションと疑わしいライブラリに焦点を当てるだけで、関連するスタックと状態を再構築するのに十分です。

コアダンプを分析する際は、実行中のプロセスが存在しないため、プログラムの実行を制御するコマンド（stepやcontinueなど）は意味をなさないことに注意してください。代わりに、スタックフレーム、ローカル変数とグローバル変数、メモリ領域、スレッドなどを検査するインスペクションコマンドを使用して、クラッシュの原因やプログラムが停止した箇所を推測する必要があります。