Linuxカーネルをgdbでデバッグ（またはディストリビューションのカーネルを使うときは当たってるパッチにも注意しよう） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2018の1日目ですΣ(ﾟ∀ﾟﾉ)ﾉｷｬｰ イントロ ほんとは別の内容にしようと思ってたのですが、進めてる途中でカーネルのデバッグをするハメになったのでカーネルデバッグをネタにしてみました。カーネルのデバッグと言っても普通のデバッグと変わらないよね〜というところがわかると思います。（｀・ω・´)<ｺﾜｸﾅｲﾖｰ デバッグの環境としてはlibvirt(qemu)で動いてるゲスト環境にホスト側からgdbでデバッグする感じです。ディストリビューションはFedora 29です。デバッグするカーネルはFedoraのカーネルで4.19.2-300.fc29.x86_64です。 テストコード テストコードは↓です。これはdebugfsのディレクトリ（大概は/sys/kernel/debug/だと思います）にopen-testってファイルを作って、その
Linux 0.01をUbuntu 10.10のQEMUで動かす - Plan9日記
「Linux 0.01の設計と実装」という記事に触発されてLinux 0.01をUbuntu 10.10上のQEMUで動かしてみた。で、gcc 4.4.5ではコンパイルできないことがわかり、gdbでリモートデバッグした。（今回はPlan 9の「ぷ」の時も出てこないのであしからず。） オリジナルの0.01は1991年にgcc 1.4で開発されていたと言うこともあり、今時のgccではコンパイルすら通らない。ということでAdbel Benamroucheの0.01-rmを使って楽をすることにした。0.01の雰囲気をてっとり早く知るには、生越さんの「Linusになろう！ -- 君にも書けるOS kernel」がおすすめ。0.01を読むのは初めてだが、0.12あたりをbochsで動くようにして遊んでいたころの記憶がよみがえる。 0.01-rmを動かす方法は、冒頭で紹介したblogに詳しいので、ここで
はじめてのgdbデバッグ | blog: takahiro okumura
仕事でagを利用していた時に出会ったバグを、先輩たちの力を借りてなんとかした話です。 先に結論を書くと、業務に用いていたagのバージョンが古いのが原因のようでした。version 0.15より古いとlockの実装に問題があるようです。 以下、問題の発覚からなんとかするまでの記録です。 発端 agが途中で止まる 時折、agのファイル操作が先へ進まなくなってしまう不具合がありました。 操作中に対象ファイルのロック状況が変わるとデッドロックが発生しているのでは？と想像。 気になってstraceでプロセスにアタッチすると、以下で停止していることが分かりました。 [pid 4589] futex(0x80517e4, FUTEX_WAIT, 32159, NULL FUTEX_WAIT futex(2)を引くと、futex(2)の書式に対する操作FUTEX_WAITの説明があります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
