RISC-V OSを作ろう (1) ～ブート処理 - VA Linux エンジニアブログ
はじめに 環境の用意 ブートプログラムを作る 動かしてみる コンパイル QEMU上で起動 GDBで制御 最後に おまけ 執筆者 : 高橋 浩和 はじめに RISC-VはMIPSアーキテクチャの流れを汲む正統派？のRISC CPUです。命令セットはシンプルですが、既存のメジャーなCPUのアーキテクチャと大きな違いがあるわけではありません。 Linux上で利用できるRISC-Vツール群も揃ってきたので、それらを使ってRISC-V用の小さなOSを実装してみようと思います。 最初は欲張らずに単純な実装を目指すことにします。 シングルコアのみサポート 64bitモードを使用 マルチタスキングを実現 タイムシェアリングスケジューリングを実装 割り込みネストは無し 保護機能は使わない 既存のBIOSやbootプログラムは利用せず、リセットエントリから全て作成する qemuの仮想マシン上で動作させる。ター
ReverseDebug - GDB Wiki
Reverse Debugging with GDB Beginning with the 7.0 release in September 2009, gdb now includes support for a whole new way of debugging called "reverse debugging" -- meaning that gdb can allow you to "step" or "continue" your program backward in "time", reverting it to an earlier execution state. Reverse debugging is only supported for a limited (but growing) number of gdb targets, including: Certa
Linuxカーネルのテスト実行とデバッグ (2) ：GDB編 - Fixstars Tech Blog /proc/cpuinfo
このブログは、株式会社フィックスターズのエンジニアが、あらゆるテーマについて自由に書いているブログです。 QEMUをカーネルの開発に使うことのメリットの1つとして、GDBによるデバッグが簡単にできることがあります。これは、GDBのリモートデバッグ機能を使用します。リモートデバッグ機能は、もとをたどれば、別のマシンで動いている（主に）組込みシステムをデバッグするために開発された機能で、対象システムにGDBと通信するためのスタブを組み込み、シリアルラインを介して通信してデバッグするというものでした。現在では、TCP/IPでの通信もサポートされており、QEMUにはそのスタブが組み込まれており、QEMU上で実行するプログラムをGDBでデバッグできるようになっています。 GDBでのLinuxカーネルのデバッグについては、今は以下にしっかりとした情報がまとまっていました。 https://www.ke
はじめてのgdb - Qiita
linux環境でC言語のデバッグを行う方にむけて、gdbの使い方を説明します。 初心者向けです。 gdbとは デバッガです。ブレークポイントを張ったり、ステップ実行したり、 変数の中身を覗いたり、書き換えたり...そういうことが出来ます。 gccと同様、linuxには標準でインストールされています。 昔からあるツールであり、コマンドラインでの操作を行います。 IDEのデバッガがどうしても使えない環境でのデバッグに役立ちます。 メリット、デメリット メリット： ・たいていのlinux環境で使える ・実行中のプログラムにattachしてデバッグ可能 デメリット: ・GUI画面がない。コマンドを覚える必要がある 使い方1:gdbから直接起動 ①ソースファイルを、デバッグ可能な方式でコンパイルする gcc -g3 test.c →a.outが生成 ※-g3とするとマクロの展開が可能となります。 ②
[OS] メモリリークの調査方法 - th0x4c 備忘録
目的 メモリリークの調査方法をまとめる。 環境 OS: CentOS 5.5 Kernel: 2.6.18-194.el5 x86_64 GCC: gcc 4.1.2 20080704 GDB: GNU gdb 7.0.1-23.el5 Valgrind: valgrind-3.5.0 サンプルプログラム メモリリークが起きるサンプルとして以下を利用する。 leak_func() が実行される度に 2048 bytes メモリリークする。 合計で 101 回 leak_func() が実行されるので 206848bytes(= 2048 * 101 bytes) リークする。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
go言語のデバッガ（delveとgdb)とcore dump - Qiita
この記事は、Fujitsu Advent Calenderの３日目の記事です。 はじめに Fujitsu Advent Calenderを作った@YasunoriGoto1です。なんか、予想以上にすごい反響があってびっくりしています。温かい言葉をくれた方には厚く御礼申し上げます。また、厳しい言葉をかけてくださった方にも今後ともよろしくお願いします。 設立に至った経緯は２日目の記事で@tnaotoが書いてくれた内容のとおりです。「社外で実施するのは手続きとか色々ハードル高いよなー」って思っていたところに、@tnaotoや「かっこいい人」を始め、色々な人から背中を押してもらった感じです。 「かっこいい人」が出た時には、「今この瞬間を逃してはならない」とばかりにかなり急いで作ったので、Advent Calendarの趣旨とかQiitaがどういう場所なのかとか、正直色々広報不足で至らなかったところ
gdbでアドレスが指す先のアドレスをdereferenceするコマンドを作った - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
gdbであるアドレスがアドレスを指している場合のdereferenceを簡単にやりたかったのでpythonでコマンド作ってみました。 これは例えばcのコードがこうで、 void func(char *p) { printf("[*] %s\n", p); } func()のディスアセンブル結果にこのような処理があるとします。 0x000000000040066e <+8>: mov %rdi,-0x8(%rbp) このとき、rbp - 8のアドレスは0x7fffffffdc68で、ここはアドレス0x0000000000602010を指しています。 (gdb) x/gx $rbp - 8 0x7fffffffdc68: 0x0000000000602010 このアドレスが指す内容は以下のようにしてdereferenceできますが、ちょっと面倒ですよね。 (gdb) x/s *(char **
gdbで効率的にデバッグするためのTips
Tips for Productive Debugging with GDBの抄訳。 Tips 1: GDB Dashboardを使おう GDB Dashboardは単一の.gdbinitファイルで、ブレークポイントで止まるたびに下図のようなクールな画面を表示してくれる。 https://github.com/cyrus-and/gdb-dashboard gdbには標準でTUIモード（cursesベースのUI）が搭載されているが、そちらは画面の乱れが頻繁に起こる。GDB Dashboardはcursesを使っていないので乱れが起きない。 スクショではOutput/messages, Source, Assembly, Threadsなど多数のモジュールを全部入りで表示しているためゴチャゴチャしているが、設定で自分に必要なモジュールだけを表示するようにできる。 訳者もしばらく使っているが、
How to spy on a Ruby program
I love debugging tools. One of the most frustrating things to me is – when I run a Ruby or Python program, I can’t find out what that program is doing RIGHT NOW. You might eagerly interrupt me – julia, you say, you can use pdb! or pry! or rbtrace!. So, let me explain. If I’m running a program on the JVM with PID 4242, I can run jstack -p 4242, and it will print the current stack trace of the Java
OSS Gateワークショップ#2にメンターとして参加してきた - ただのにっき(2016-03-26)
■ OSS Gateワークショップ#2にメンターとして参加してきた これを書いてるのは4月も5日になってからなので、だいぶ間があいてしまった……って前回も同じこと書いてる(笑)。OSS Gateには日記を書くのを遅らせるとか、そういう呪いでもあるのか(ないない)。 OSS Gateワークショップの2回目に、ふたたびメンターとして参加してきた。メンター足らんかもとか書いておいて、蓋をあけたらビギナー*1のドタキャンや無断欠席が続出して、メンターが大勢余ってしまった。やっぱあれだね、こういうコミュニティ活動でドタキャンが出ると主催者がすごく困るってことを身を持って知ってるか(メンター)、知らないか(ビギナー)という違いが出てるような気がするね。困るんですよ? 何が困るって、せっかく集まってもらった歴戦のメンターたちが手持ち無沙汰になってしまう*2。ということで、前回はビギナーだったけど今回から
実行中のマルチスレッドプログラムの特定スレッドのみ停止(SIGSTOP的な)させる方法 - ablog
@yoheia gdb -p LWP で特定のスレッドだけ止められますよ。— Tsukasa Hamano (@hamano) 2016年3月29日 @hamano "gdb -p LWP" でサクッとできました！ありがとうございます。 $ ps -u grid -lLf|grep css $ gdb -p 3449 -> LWP:3449 のステータスが t になりました— yohei-a (@yoheia) 2016年3月29日 @yoheia gdb -iex="set non-stop on" -iex="set target-async on" -p プロセス して cont -a してから特定プロセスを interrupt してもいいですね。こちらのほうが自由にスレッド間を行き来できていいかも。— Tsukasa Hamano (@hamano) 2016年3月29日
LLDBとかいう次世代高性能デバッガ - Qiita
LLDBとの出会い LLVMを読むためのサポートとしてデバッガを使おう、と思い立ち調べていたら、GDBではなくLLDBという代物があるらしい。知らなかった。しかも結構前からあるみたい。 以下、LLDBのページより抜粋したものを我的翻訳。 LLDBとは？ LLDBは次世代の高性能デバッガである。Clang expressionパーサとかLLVM Disassemblerのような、より大きなLLVMプロジェクトにおいて再利用しやすいコンポーネントとしてビルドされる。 今のところ何が嬉しいのかよくわかんねぇけど。 LLDBは次世代の高性能デバッガである。 この一文だけで十分なモチベーションになる。 以降、LLDBチュートリアルをまとめていく。飽くまで筆者の理解であり、メモ程度。 LLDBチュートリアル コマンドの構造 LLDBのコマンドは、GDBより構造的な構文になっている。コマンドは、全て以下
gdbを使ったrubyのデバッグ - クックパッド開発者ブログ
技術部の国分 (@k0kubun) です。 先日byebugの高速化を行っていた最中、変更を加えたbyebugを使っていると一定の確率でrubyがSEGVするバグを発見しました。 私はC言語のコードのデバッグの経験はなかったのですが、デバッガの使い方を調べながらSEGVの原因調査を行いパッチを送ったところ無事取り込まれ、最新の高速なbyebugが安全に使えるようになりました。 その際、ruby自体をデバッグするために必要な情報が分散していて大変だったので、まだrubyのデバッグをしたことがないけれどやってみたいという人を対象に、gdbというデバッガを使ったrubyのデバッグの方法を紹介します。 デバッグ用にrubyをビルドする デバッグ時に変数名やソースコードなどの情報を見るためには、最適化オプションをオフにしてデバッグ用にrubyをビルドしておく必要があります。 rubyのデバッグ用ビル
デバッグ/コアダンプ - S.T.K Wiki
コアダンプ プログラムのとある時点でのメモリやレジスタの内容をファイルに保存したもの。主にプログラムが異常終了した際の原因特定のために使用される。 コアダンプを生成するには 一昔前は特に設定しなくてもSEGVするとcoreを吐く環境もあった気がするが、イマドキ(?)のLinuxディストリでは 以下のコマンドを実行しないとコアを吐かないようになってるのがほどんどだ。(以下の解説では主にLinux環境を想定している) $ ulimit -c n # nはcoreファイルの最大サイズ(KB単位)coreファイルのサイズに上限を設けないあるいは気にする必要がないのであれば以下でもいい。 $ ulimit -c unlimitedまた、参考文献によるとcoreファイルの生成を抑制するのはシェルの仕事らしい。 言われてみればulimitコマンドはシェルの組み込みコマンドだ。 $ which ulim
gdb で MySQL 5.0.96 のスロークエリログを追ってみる - takatoshiono's blog
1つ前のエントリ Query_time - Lock_time > long_query_time - takatoshiono's blog で以下のように書いた。 ソースコード MySQL 5.0.96 で Lock_time が 0 になるのが気になったのでソースをダウンロードしてきて追ってみた。Lock_time で grep すると以下のコードに辿り着くので変数名を頼りに少しさまよってみたのだが、力不足で追いきれなかった。無念。 Webエンジニアのための データベース技術[実践]入門 (Software Design plus) を読んで動的解析の方法を学習したので試してみる。 MySQL 5.0.96 をデバッグモードでインストール kamipo/mysql-build · GitHub を使って 5.0.96 を —with-debug でインストールした。 最初 sed で
cgdbとgdbのTUIモードでGoのコンソールデバッグをしてみる
デバッグにはGUIを使ってもよい派なので、liteIDEとかIntellijを使うほうが幸せになりそうですが、Goのコンソールデバッグするために、gdbをコンソールでちょっと使いやすくしたcgdbと、gdbのTUIモードを試してみました。 なお、Goでこれらを利用するにはまずgdbを最新のものにする必要があります。詳細は以前の記事「MacでGoのデバッグ環境を構築する」を参照してください。 cgdb cgdbの構成は2ペイン表示になっており、上がコードで下がgdbコンソールになっています。 2つのペインの往き来はvi風に行います。上のコードモードにはESCで入ります。gdbコンソールに戻るにはiを押します。 上のコードモードではスペースキーで現在行にブレークポイントを張れたりします (Solarizedを使っているせいで現在行がすごくわかりづらいです)。 なお、tの一回だけ止まるブレークポ
Easier Go debugging on the command line with CGDB
(EDIT: Just a little plug: See also my course on linux commandline productivity techniques: http://www.udemy.com/command-line-productivity ) Here I quickly go through how to use CGDB to debug a Go program in an easier way than with the GDB debugger directly, since it continuously shows the code context. I cover the basic GDB commands on how to navigate the code, set breakpoints, step line-by-line
MPI並列プログラムのデバッグにGDBを使う方法 — TodoLab
1.1 実行方法 次のスクリプトを用意しておきます． run.sh: #!/bin/bash echo "Runnnig GDB on node `hostname`" xterm -e gdb --args $* exit 0 MPIプログラムの実行: $ mpirun -np 2 -x OMP_NUM_THREADS=4 run_gdb.sh ./parallel_bench --mpi -r 8 -p 8 param.in.xml すると，各プロセスごとに xterm が立ち上がります．例の場合 -np 2 とし ているので 2枚の xterm が立ち上がります．xterm ごとに gdb も立ち上がり ます．その後，各 xterm で gdb のコマンド r (run) を実行すると自分のプロ グラムが走りはじめます．プログラムがクラッシュする場所を特定したいだけ なら以上の手
CoreからRubyのバックトレースを表示するgdbruby.rbを作った
gdbperl.plというスクリプトがあります。そんｋする樋口証さん作の、gdbを操作してPerlのプロセスのバックトレースを取るツールです。生きているプロセスだけではなく、coreを取っておけばそのcoreからバックトレースが取れるのが特徴です。 gcoreというコマンドが/usr/binあたりにあって、これを使えば走っているプロセスのcoreを取得することができます。よって、本番環境で気軽にcoreを取ってgdbperl.plにかけることによって、刺さっているポイントを見つけたりすることができます。超便利。 くわしくは、Perlスクリプトをgdbでデバッグを参照ください。 んで、その便利なgdbperl.plをRubyに移植してみました。その名もgdbruby.rb。単純。 gdbruby.rb 使い方とか Rubyはデバッグシンボル付きのものをご用意ください。 生きているプロセスにア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OSS Gateワークショップ2016-03-26: knokmki612: twm: 作業ログ · Issue #23 · oss-gate/workshop
