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..
OProfile
OProfile とはOProfile はカーネルも含めたシステム全体のプロファイリングを行います。システ ム全体の処理時間が、カーネル、各カーネルモジュール、各ユーザープログラム、各 共有ライブラリのうちのどの部分で消費されたかという統計を得ることができます。 この統計はバイナリイメージごと、あるいは関数ごと、より詳細にアドレスごととい うように多様な形式で表示できます。OProfile はパフォーマンスカウンタを利用してハードウェアイベントに基づいた プロファイリングを行うことができます。パフォーマンスカウンタによって測定でき るイベントは、アーキテクチャーモデルにより異なりますが、例えば、キャッシュミ ス、クロックサイクル、TLB ミスといったイベントを測定できます。 そのため、さまざまな側面からプロファイリングを行うことが可能です。2.5 系のカーネルのバージョン 2.5.43 か
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 を忘れず
でらうま倶楽部 : iPhone Objective-Cではないコードのメモリリークを特定するには(今回はソース付き)
2010年08月05日15:38 カテゴリiPhoneプログラム iPhone Objective-Cではないコードのメモリリークを特定するには(今回はソース付き) 今回はメモリリークの話です。 iPhoneでのメモリ管理ですが、Objective-Cのクラスをフル活用してコードを書いているウチは問題ないと思います。InstrumentsのLeaksを使えばコードのどの場所で確保されたメモリかが一目瞭然だと思うからね。 (きっとC++でもそんな感じに違いない) なーのーでーすーがー！ 問題なのがCのmalloc()とかcalloc()とかrealloc()とか。これ、InstrumentsのLeaksでも「Malloc area 8K」とかって表示されるんで、その表示の中からメモリリークを探し出すのが至難の技….。 まぁメモリ確保時にクラス名の指定も何もないんだから仕方ないのは判ってるんで
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でメモリダンプして構造体を発見する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_
再入不可能な関数を C で実装する - いやなブログ
再入不可能な関数を C で実装する 一度実行したら二度と中身を実行できなくなる再入不可能な関数を C で実装してみます。通常、このような関数はシングルトンなどの静的なデータの初期化に使いますが、ここではデータについては考えないことにします。 static 変数をフラグに使う まずは最も単純な方法から見ていきます。次の関数は static 変数をフラグに使って再入を防いでいます。厳密に言えば関数そのものには入ってしまっていますが、ここで気にしないことにします。 void once(void) { static int entered; // 最初は 0 if (entered == 1) { // すでに入ったことがある場合は return; // すぐ出る } entered = 1; // 初回の場合のみ、何かを実行する } この方法はシングルスレッドのプログラムではうまく動きますが、マ
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)
□株 ▽ソフトウェア --- Exkabu
作者ホームページサービス（hp.vector）は終了いたしました。 長らくのご利用、ありがとうございます。 ご不明な点があれば、お問い合わせページをご覧の上、お問い合わせください。 ※15秒後にトップページに戻ります。 (c) Vector HOLDINGS Inc.All Rights Reserved.
iPhoneのデバッグハック
5. backtrace()の使い方//スタックトレースの出力[mstrappendString:@"Stack:"]; void* callstack[128];inti, frames = backtrace(callstack, 128); char** strs = backtrace_symbols(callstack, frames); for (i = 0; i < frames; ++i) { [mstrappendFormat:@"%s",strs[i]]; } 7. 出力例 Signal:10 Stack: 0 ibisMail 0x0006989d dump + 64 1 ibisMail 0x00069b4b signalHandler + 46 2 libSystem.B.dylib 0x31dcd60b _sigtr
OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん
OMakeすごい。OMakeはマジですごい。 OMakeはGNU makeの代替品みたいなものなんだけど、正直なところこのツールの強力さはGNU makeと比べると失礼なくらいすごい。これのおかげで、「コード修正→ビルド→デバッグ→コード修正→・・・」のループの、ビルドにあたる作業がほぼ消え去った。 ファイルの依存関係の解析がとにかくすごい。よくあるユースケースなんかの場合、最小限の手間でほぼ完璧に依存関係を網羅して、よしなにビルドしてくれる。 とりあえず、はやみずが実際に使ってみたケースを例にとってそのすごさの一端を紹介しようと思う。 case study 論より証拠ということで、自分が OMake を試しにつかってみたケースを紹介する。C言語でスタティックライブラリを作っていて、それに加えて簡単なテストプログラムを書いている。 /include/ 以下にヘッダファイルが全部ある /sr
![OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん](https://cdn-ak-scissors.b.st-hatena.com/image/square/04e015dad70084a57fdfa9a2686c0c93441c5d2d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127128184977%2F17680117127128193858%2F1557447212)
Core War - Radium Software
メモリ破壊と言えば…… Core War （コア戦争）というプログラミング・ゲームの一種がある。 Core War では Redcode と呼ばれる仮想アセンブリ言語が用いられる。この言語を使って書かれたプログラムを，同一のメモリ空間上で実行し，互いのプログラムを破壊し合う。それで，最後まで止まらずに生き残ったプログラムが勝ちとなる。詳細については Coding Horror の紹介記事がまとまっていて参考になる。 面白いのは，とにかく自己複製を行いまくるプログラムが強い，というわけではないこと。複製は行わず，たくさんの停止命令をメモリ上にバラ撒いて，相手がそれを踏んで止まるのを待つという戦略もある。あるいは，相手のコードの位置を特定してから破壊しにかかる手もある。 Core War とバグによるメモリ破壊は色々とわけが違うけれど，デバッガーのメモリダンプと睨めっこしながらステップ実行でメ
最低限の Smalltalk デバッガ入門（Squeak システム向け） - Smalltalkのtは小文字です
Smalltalk ではスタックフレームも「コンテキスト」と呼ばれるオブジェクトです。ちなみに、実行中のコンテキストに容易にアクセスできるようにわざわざ thisContext という擬変数まで用意されています。Smalltalk には予約語は全部でたった６つしかない（他は self、super、nil、true、false）うちのひとつを使うわけですから、これはある意味、破格の扱いです。 こうした背景もあってか、はたまた私の単純な思い込みでか、Smalltalk のデバッガは「コンテキスト（や、その連なりによって表現されるコールスタック）をブラウズするためのツール」という性格が強いように感じられます。クラス用ブラウザがクラスブラウザ、インスタンス用がインスペクタなら、デバッガはコンテキスト向けに特別に用意された“第三のブラウザ”といったところでしょうか。 ▼デバッガの起動 デバッガを起動
Rails 2.0でデバッグをする新しいやり方 - Hello, world! - s21g
比嘉さんからciteされたみたいなので、取り急ぎ新しい情報を吐き出しておこうと思います。 そろろろRailsについて本音を書いてみるか 後、デバッグの環境は、Javaに比べて貧弱だと思う。Railsでデバッグをする７つの方法を見てほしい。IDEでソースにブレークポイントを設定(ソースコードを書き換えるのではなく)して、ステップイン、ステップオーバー、メモリの状態を見たりなんてのに慣れているJavaから比べると、すっごく大変に見える。 喜ばしいことに、Rails 2.0ではruby-debugを使ったdebuggerが正式に採用されました。 これの使い方は非常に簡単です。 まずは、以下のようにブレークポイントをコード中に書き込みます。
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ダンプされたcoreを元にエラー原因を解析する方法 - Hello, world! - s21g
http://www.a.math.ryukoku.ac.jp/~hig/course/compsci_2002/21/
http://www.machu.jp/posts/20090307/p01/
