この記事はLinux Advent Calendar 2018の1日目ですΣ(ﾟ∀ﾟﾉ)ﾉｷｬｰ イントロ ほんとは別の内容にしようと思ってたのですが、進めてる途中でカーネルのデバッグをするハメになったのでカーネルデバッグをネタにしてみました。カーネルのデバッグと言っても普通のデバッグと変わらないよね〜というところがわかると思います。（｀・ω・´)<ｺﾜｸﾅｲﾖｰ デバッグの環境としてはlibvirt(qemu)で動いてるゲスト環境にホスト側からgdbでデバッグする感じです。ディストリビューションはFedora 29です。デバッグするカーネルはFedoraのカーネルで4.19.2-300.fc29.x86_64です。 テストコード テストコードは↓です。これはdebugfsのディレクトリ（大概は/sys/kernel/debug/だと思います）にopen-testってファイルを作って、その
はじめに 学校で習わないが(習う学校もある)、現実に必要になるプログラミング技術に、低レイヤプログラミングなどと呼ばれるものがある 厳密な定義は聞いたことがないし、おそらく存在しないとは思うが、大体のみんなの共通認識として、 「高級プログラミング言語を使わないプログラムを書き、OSで抽象化されないデバイスの機能を使う」といったような認識があると思う。 筆者の経験から言わせてもらうならば、低レイヤプログラミングに関する知識は、プログラミングにおいてあらゆる場面で、常に、少しずつ役立てられる知識だと言えると思う。 普段はRubyやPHPなどを書いてる人であったとしても、メモリが足りなくなった場合や、デバッガを使っている場合、性能が足りなくなった場合など、 厳しい環境におかれた時に低レイヤプログラミングに関する知識が必ず役に立つ場面が来ると信じている。 また、役に立つかどうかは置いておいても、「
マイコン用デバッグプローブであるJ-Linkが超便利なので紹介します。 J-Linkを購入しなくても、STLink・LPCLinkをJ-Link化する方法も紹介します。 J-Linkとは J-Linkとは、SEGGERの開発しているマイコン用デバッガです。 SEGGER: Debug Probes J-Link ※画像はSEGGERのWebページより 対応しているCPUは非常に多く、 ARM Cortex A,M,R ARM 7,9,11 Microchip PIC32 Renesas RX で使えるみたいです。 (自分はARMのCortexMシリーズにしか使ったことがありません) J-Link Overview of Supported CPUs and Devices 例えば趣味でARMのCortex-Mシリーズを開発する場合、ST-LinkやらLPC-Linkといったデバッガを使うか
前回の続き。 #従来のremoteモードではできなくて、extended-remoteモードで可能になったこと それは、gdb側からの操作で新たなデバッグ対象プロセスを起動することです。つまり run コマンドの実行。 また、デバッグ対象プロセスをまだ起動していない状態で、gdbとgdbserverの間でファイルを転送することができます。 この2つを合わせると、「修正された実行ファイルをターゲットに送信して、それを起動してデバッグを開始する」というのがgdb内で完結できます。 #リモートデバッグのサイクル 以下の1-5を繰り返す。 ソースコードを修正する コンパイル、リンクして実行ファイルを作成する 実行ファイルをターゲットに転送する 実行ファイルを起動する ブレークポイントをかけたり、変数を見たりしてデバッグ 従来のremoteモードでは3はscpで転送したりNFSにしたり別の方法での実
gdbからgdbserverに接続してリモートデバッグするときに従来のremoteモードに加えて、extended-remoteモードが使用できます。 #従来のremoteモードとextended-remoteモードの比較 remoteモードではgdbserverを起動する段階でどのプロセスをデバッグ対象とするのかを決める必要がありました。(新たにプロセスを起動するか or 実行中のプロセスにアタッチするか) そして、デバッグが終了してgdbとgdbserverの間の通信が切れた段階でgdbserverのプロセスは終了していました。 extended-remoteモードではデバッグ対象を決めずにgdbserverを起動させておくことができ、gdbと接続した後にデバッグ対象のプロセスを決めてアタッチすることができます。またデタッチした後もgdbserverは生き続けて、再度同じまたは別のプロ
他のプロセスを中断せずに、その出力をミラーリングして新しくパイプで繋ぐ、そんなことはできるのでしょうか。 straceやgdbといったコマンドは一体どういう仕組みで動いているのでしょうか。 ptraceシステムコールを使い、プロセスが呼ぶシステムコールを調べて出力を覗き見するコマンドを実装してみたいと思います。 ptraceシステムコール Linuxを触っていると、いかにプロセスを組み合わせるか、組み合わせる方法をどれだけ知っているかが重要になってきます。 パイプやリダイレクトを使ってプロセスの出力結果を制御したり、コードの中からコマンドを実行して、終了ステータスを取得したりします。 プロセスツリーやプロセスグループを理解し、シグナルやnohupコマンドを使ったりします。 プロセスの扱いに慣れると疑問に持つのがstraceやgdbの仕組みです。 プロセスの実行しているシステムコールを出力し
GDBでPython scriptを実行する
最近（少なくともversion 7以降)のGDBは、Python scriptを実行できます。実行には、従来のGDBマクロと同じくsourceコマンドを使用します。 早速、試してみましょう。次のようなPython scriptを用意します。 $ cat hello.py #!/usr/bin/env python import sys sys.stdout.write('Hello, my first script.\n') GDBを起動して、実行します。 (gdb) source hello.py Hello, my first script. Python scriptからのGDB機能の利用 次に、Python scriptからGDBの機能を使用する例を紹介します。gdb.execute()関数を使用すれば、GDBのコマンドラインで行う操作を実行できます。 サンプルのデバッグ対象として
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
