GDB スタブを書いてみよう その2 - higepon blog
gdb 7.0 をダウンロードする。 ./gdb/m68k-stub.c ./gdb/m32r-stub.c ./gdb/i386-stub.c ./gdb/sparc-stub.c 前回の調査で sparc-stub.c が良くまとまっている事が分かっているので見ていこう。 さっそく GDB コマンドなる物があるらしく説明がある。レジスタやメモリの read/write、resume, stop, kill など。 * command function Return value * * g return the value of the CPU registers hex data or ENN * G set the value of the CPU registers OK or ENN * * mAA..AA,LLLL Read LLLL bytes at address AA..
貧乏だってプロファイリングは出来る！！ - poor man's profiler
従来より、プロファイリングのためのソフトウェアと言えば高価なものが中心であった。もっと安く、お金を掛けずに、簡単に、早くプログラムのボトルネックを探し出す方法はないのか？！ということで編み出されたプロファイリングテクノロジーがある。その名も、「poor man's profiler」だ。 poor man's profilerの全容は、次のページで知ることが出来る。 Poor Man's Profiler http://poormansprofiler.org/ poor man's profilerは、現Facebook（元MySQL ABのサポートエンジニア）のDomas Mituzasによって開発されたプロファイリングテクノロジーである。以下が、その全ソースコードである。 #!/bin/bash nsamples=1 sleeptime=0 pid=$(pidof mysqld) f
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*)
debugging with GDB
gdbとは gdbは The GNU Project Debuggerのことです。 デバッグのためのツールです。 プログラムがエラー終了するが、どこが悪いのかわからない… というような時に便利です。 準備 デバッグ対象プログラムのコンパイル コンパイルしたプログラムにデバッグ情報を含めておくと、 デバッガでプログラムのソースを参照できるなど、 デバッグが非常に楽になります。 gccやUNIXのccでは、コンパイル時に「-g」オプションを付加すると デバッグ情報を生成します。 最適化オプション「-O」と デバッグオプション「-g」の両方は 同時に指定できないコンパイラもあるので注意してください。 gccは同時に指摘できます。 なお、FreeBSDやRedHat Linuxのccの正体はgccなので、 「-O」と「-g」を同時に指定できます。 makeでコンパイルしている場合には、 「-g」オ
gdb + core 解析 - utahta blog
core ファイルを解析するメモ。 下準備 まず意図的に SEGV させるコードを書く。 $ vi a.cpp #include class CPrint { private: int m_number; char *m_str; public: CPrint() : m_number(10), m_str(NULL) {} ~CPrint() {} void print(){ // ここで SEGV る予定 printf( "%d, %c\n", m_number, m_str[0] ); } }; int main() { CPrint p; p.print(); return 0; } 続けて core を出力させる設定。環境は Linux CentOS 5。 $ ulimit -c unlimited core dumped 下準備で作成したソースコードをコンパイル。-g を忘れず
Cutter導入事例: Senna (1) - 2008-07-25 - ククログ
Sennaの単体テストフレームワー クとしてCutterを導入したときの手順です。自分のプロジェクトに Cutterを導入するときの参考になるかもしれません。全体として そこそこ長くなってしまったので、何回かに分割して紹介することに します。 内容はSennaのリポジトリ でやったことの一部です。リポジトリは公開されているので、試行錯誤の 後などをみたい場合はコミットを追いかけるとよいでしょう。また、ここで は断片としてしか出てこないコードについても、リポジトリの中には完全な 形で入っています。 もし、まだCutterについて知らない場合は、はじめにチュートリ アル を読んでください。 はじめに まず、Sennaについて簡単に説明します。 Sennaは組み込み型の全文検索エンジンで、その機能をライブラリ として提供します。SennaのAPIはbasic APIやadvanced APIなど
gcc+gdbによるプログラムのデバッグ 第2回 変数の監視、バックトレース、その他のコマンド
前回までに、デバッガを使用する上での最低限のことを覚えました。 ステップ実行 変数の表示、変更 ブレークポイント 今回は少しレベルを上げて、よりデバッガを使いこなすためのコマンドを紹介します。 ウォッチポイント ウォッチポイントはブレークポイントに近いものですが、ブレークポイントのように「ある地点に遭遇したら停止」ではなく、「監視している変数を操作したら停止」という流れになります。 ファイル内から該当する変数名を探せばいいと考えるかもしれませんが、C言語ではポインタによる変数の別名を付けることが可能であるため、そう単純にはいきません。 書き込みの監視 あまりよいサンプルが思いつかなかったため、簡単で無意味な例を示します。 counter.c #include <stdio.h> void set_counter(int *); int count = 1; int watchee = 0;
Omicron Linux/GDBを使ってコードを追っかける
Linux あんまりGDBを使っている人がいないみたい．OS/omicronV4 みたいに数人でコンパイラから作って貧弱な環境で(体力をトレードオフに(^^;)ひぃひぃ言っているわけじゃないんだから使えるものは活用しないと． はじめに 構造体のメンバをたどるときなどにデバッグ情報が必要になるので，前もって -g オプション付きでカーネルをコンパイルしておくこと．/usr/src/linux/Makefile の CFLAGS_KERNEL を次のように編集すれば OK． CFLAGS_KERNEL = -g また，次のようにコマンドラインから実行しても OK． # EXTRA_CFLAGS=-g make gdb の起動は次のようになる．/proc/kcore にアクセスするため，su しておく必要がある．/proc/kcore とはPCに搭載された物理メモリを覗くためのインタフェースであ
CGDB - curses interface to gdb - メモ帳
http://cgdb.sourceforge.net/ curses を使った gdb インターフェイス。 vi キーバインドで gdb を操作できる。かなりいい感じ。 $ cgdb -- a.outで起動。上側のウィンドウがソースウィンドウ(CGDB Mode)。下側が GDB Window (GDB Mode)。 i と Esc で2つのウィンドウ間を行き来できる。 ソースウィンドウで使えるコマンドの一部： Space ブレークポイント設定 j k カーソル移動 / ? 検索 o ファイル選択ウィンドウを開く T デバッギへの入力をタイプするための TTY ウィンドウを開く i GDB ウィンドウへ s c n r step continue next run (:set shortcut しているときのみ有効) : コロンコマンド。:set :run :q など 設定ファイルは ~
GDBデバッギング覚え書き - しばそんノート
使い方をよく忘れるので…。 リファレンス的なものではなく、要点のみの覚え書きです。 以下の記述は gcc 4.1.2 gdb 6.8 を前提としています。 コンパイル "-g"オプションは必須 "-O"系オプション（最適化）は付けない*1 stripしちゃダメ プログラムの実行 $ gdb (progoram) で起動して (gdb) runプログラムに引数を与えることもできます。また、標準入力、標準出力もリダイレクトで指定できます。 (gdb) run (arguments) < (input file) > (output file)以下のコマンドで環境変数も設定できるので、この辺を組み合わせればCGIのデバッグも可能です。 (gdb) set env LANG=C環境変数の確認は以下の通り。 (gdb) show envCGIのデバッグをする場合はこんな感じになるのかな？ (gdb)
reference card-j 01.3.12 10:51 PM - 1 - GDB早見表 GDB Version 4 [] surround optionaI arguments ... show one or more argument 注意： Mac OS XのGDBで動作確認していません。 主要命令 gdb program [core] programをデバッグ [コアダ
reference card-j 01.3.12 10:51 PM - 1 - GDB早見表 GDB Version 4 [] surround optionaI arguments ... show one or more argument 注意： Mac OS XのGDBで動作確認していません。 主要命令 gdb program [core] programをデバッグ [コアダンプcoreを使用] b [file:] function [fileの]functionにブレークポイント設定 run [arglist] [arglist付きで]プログラム実行 bt バックトレース: プログラムスタック表示 p expr 全式の値を表示 c プログラム実行継続 n 次行、関数コールをステップオーバ s 次行、関数コールをステップイン GDB起動 gdb GDB起動、デバッグ対称ファイル指定
gdbでメモリダンプして構造体を発見するTips - I am Cruby!
gdb知りたい構造体が見たくても見れない場合に便利。例えば、デバッグシンボルがないバイナリ内でSEGVしている場合など。*1 こんなコードを用意してみた。特徴コンパイルは-gなしhg->comment = "Hellow!" だとSEGVが発生 #include #include struct hoge { int id; char *comment; }; void throw_segv(char *comment) { int test[1000]; if(!strcmp(comment, "Hellow!")) test[-100000] = 9; } int main(void) { struct hoge *hg; hg = malloc(sizeof(struct hoge)); hg->id = 2565; hg->comment = "Hellow!"; throw_
GDB でレジスタを見る - higepon blog
GDB でレジスタを表示するときに (gdb) info register rax # もしくは i r rax としていたが、レジスタは変数としても参照可能なことを知った。頭に $ をつけるだけ。 (gdb) print/x $rax 変数として参照できるので、操作の度に自動でレジスタを表示する display コマンドを設定する事が可能。 (gdb) display $rax また register をポインタに cast してごにょごにょとかも可能。 (gdb) print/x ((intptr_t*)$rax)[1] $1 = 0x415a2c .gdbinit # http://0xcc.net/blog/archives/000126.html set history save on set history size 10000 set history filename ~/.
Sakai Hiroaki's Home Page
このホームページは以下に移動しました． ブックマークを張り直してください． ５秒後に自動的に移動します． http://kozos.jp/kozos/kozos17.html
GDBで歴史をさかのぼれるように!なりました! GDB 7.0 の新機能Reverse Debuggingを使ってみた - 日記を書く [・w・] はやみずさん
Twitter上で、@alohakun が言及していた GDB の reverse debugging の機能を使ってみました。 GDB にトレースと逆実行機能入ったのか。 http://www.gnu.org/software/gdb/news/reversible.html http://twitter.com/alohakun/status/4481139191 まずは簡単な使い方を説明したあとに、インストール方法を説明します。 こんなときに便利 「変なこと」が起きている大体の場所がわかっているとき デバッグ中に、大体どこで変なことが起きているかはわかっているけど、細かい場所は特定できていないとき、reverse debuggingが効果を発揮します。 GDBでステップ実行をしていて、「しまった!行きすぎた!」という経験はよくあると思います。こういうとき、今まではプログラムの実行を最
![GDBで歴史をさかのぼれるように!なりました! GDB 7.0 の新機能Reverse Debuggingを使ってみた - 日記を書く [・w・] はやみずさん](https://cdn-ak-scissors.b.st-hatena.com/image/square/5525a2830381c6797ff7950668c3d6fe91891b31/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127128184977%2F17680117127128190416%2F1557447110)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
ダンプされたcoreを元にエラー原因を解析する方法 - Hello, world! - s21g
RAT Portal Develop
http://www.a.math.ryukoku.ac.jp/~hig/course/compsci_2002/21/
http://www.ie.u-ryukyu.ac.jp/~e065723/pukiwiki/index.php?QEMU%2F%C2%E82%B2%F3%20GDB%A4%CB%A4%E8%A4%EBKernel%A4%CEDebag