Debugging with GDB - GDBファイル
GDBはデバッグ対象となるプログラムのファイル名を知っている必要があります。 これは、 プログラムのシンボル・テーブルを読み込むためでもあり、 また、 プログラムを起動するためでもあります。 過去に生成されたコア・ダンプをデバッグするには、 GDBにコア・ダンプ・ファイルの名前を教えてやらなければなりません。 ファイルを指定するコマンド 実行ファイルやコア・ダンプ・ファイルの名前を指定したい場合があります。 これは通常、 GDBの起動コマンドへの引数を利用して、 起動時に行います （GDBの起動・終了を参照）。 ときには、 GDBのセッション中に、 異なるファイルに切り替える必要がでてくることがあります。 あるいは、 GDBを起動するときに、 使いたいファイルの名前を指定するのを忘れたということもあるかもしれません。 このような場合に、 新しいファイルを指定するGDBコマンドが便利です。
gdb の使い方・デバッグ方法まとめ
たとえば、変数 var の値を2進数で表示したい場合は、次のように指定します。 (gdb) p/t var 一覧表示 whatis 変数の型を調べる。 info b 今設定しているブレークポイントの一覧を表示 セグメントフォルトをした後に利用すれば、どの関数で発生したか確認できます。 info stack 関数の呼び出しスタックの一覧を表示 info Thread 存在しているスレッドの一覧を表示 異なるアドレスにおける処理継続 以下のコマンドを使用することで、ユーザが選択したアドレスにおいて実行を継続させることができます jump linespec linespecで指定される行において、実行を再開 jump *address addressで指定されるアドレスにある命令から、実行を再開 アドレスが分かっている場合のメモリリーク出力 xはhexの意味です。 (gdb) p (char*)
GDBによるテスト自動化への試み - ファイヤープロジェクト
…GDBの機能を使用すると,テストを自動化できないだろうか…そんな疑問がよぎったのでちょっと試してみた. はじめに 基本方針 デバッガによるテスト 自動化へ向けて コマンドファイルの作成 量産 もう一越え はじめにまず,最初にこの頁はCによる開発を前提にしていることを断っておく.テストというと,最終的には実際に出来上がったものを対象に外部使用をチェックすることになる.しかし,そこに至るまでに関数単位でのテストをボトムアップでやっておかないと,障害の切り分けが繁雑になったり,モノができあがってから「この関数に問題があるので全体の構造をかえる必要がある」なんてことがわかっても困る.ということで,この頁では関数単位のテスト,すなわち関数の呼び出しとその結果のチェックを自動化することを目指してみる. 基本方針残念ながらテストの自動化といっても,全てが自動なわけではなく,テストを自動的に行なってくれ
tips : tips/02.プログラミングなど/C言語/C言語のLinux環境.txt
gccとかgdbとかgoogle-perftoolsとか、C言語のLinux環境関連のメモ コンパイル # バージョンを確認する gcc -dumpversion # オプションつけないでコンパイル gcc xxx.c → a.out という名前の実行ファイルが出来る。実行権限もつけてくれるようだ。 # 実行ファイル名を指定したいとき gcc -o xxx xxx.c → xxx という名前の実行ファイルが出来る # その他のオプション -Wall : 警告を全部みせる -O1 (-O) : ゆるい最適化 -O2 : 普通の最適化 (普通はこれをつかうそうだ) -O3 : 強力な最適化 (コンパイラのバグを引き当てたりするそうだ) -g (== -g2) : デバッグ用のシンボル -g3 : マクロも展開する -g
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
