You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに 環境の用意 ブートプログラムを作る 動かしてみる コンパイル QEMU上で起動 GDBで制御 最後に おまけ 執筆者 : 高橋 浩和 ※ 「RISC-V OSを作ろう」連載記事一覧はこちら ※ 「RISC-V OS」のコードはgithubにて公開しています。 はじめに RISC-VはMIPSアーキテクチャの流れを汲む正統派?のRISC CPUです。命令セットはシンプルですが、既存のメジャーなCPUのアーキテクチャと大きな違いがあるわけではありません。 Linux上で利用できるRISC-Vツール群も揃ってきたので、それらを使ってRISC-V用の小さなOSを実装してみようと思います。 最初は欲張らずに単純な実装を目指すことにします。 シングルコアのみサポート 64bitモードを使用 マルチタスキングを実現 タイムシェアリングスケジューリングを実装 割り込みネストは無し 保護機能は使わ
自作Goコンパイラ babygo でマルチスレッドを動かすこと(=子スレッドの作成)に成功しました。 実は以前に挫折していた 1年半前に 一作目のGoコンパイラ minigo でもマルチスレッドに挑戦したことがあるんですが、そのときは子スレッド生成後すぐに Segmentation Faultが起きてしまい、解決方法わからずあきらめたのでした。(動かなかった syscall cloneの残骸 https://github.com/DQNEO/minigo/blob/5ab7420fbca2f65d81bc761d5cbe51a2b28953a8/internal/runtime/runtime.s#L41-L61 ) (当時は gdb でステップ実行すると他のスレッドも処理が進むということを知らなかったので、ただただ謎の挙動にしか見えなかった) 今回やったこと 今回は以下のように要素技術を
I'm trying to find a better debugging experience for my current projects (zig/c, nixos). Usually I just use vanilla gdb. Here is a debugging session I ran recently on this linux x64 binary. 1. Open and run until crash. [nix-shell:~/focus]$ gdb ./test ... (gdb) run ... Test [1/1] test "search forwards"... reached unreachable code /nix/store/5g4w66g606d46w8pmzwzq7flrlk3k7cs-zig/lib/zig/std/debug.zig
プログラムの動的な振る舞い、特にメモリアクセスの様子をみてみたくなることがあります。 たとえば、2017年のデザインガイアで発表されていたFPGAアクセラレータ開発を支援するためのツール環境では、ValgrindとGDBを使ってメモリアクセスの様子を可視化していて、面白そうだな、やってみたいなと思わされます。 とりあえず Valgrind + GDBでメモリアクセスを確認する方法を、ちょっと試してみました。 Valgrindを使ってみる まずはValgrindを使ってみます。ターゲットはfree忘れの簡単なプログラムです。 #include <stdlib.h> #include <strings.h> #define N (100) #define M (128) void dut() { char *ptr; for(int i = 0; i < N; i++) { ptr = (ch
GDBがeBPFのデバッグをサポートした。 GNU Debugger Adding eBPF Debugging Support - Phoronix eBPFというのはLinuxカーネル内の仮想マシンだ。 もともと、BPF(Barkley Packet Filter)という仮想マシンがあった。これはネットワークのパケットフィルタリングをするための仮想マシンで、レジスターベースのRISCプロセッサーを模した命令セットになっている。 カーネル内で安全にユーザーコードを実行するというのは需要があるので、BPFをより汎用的に使いたいという声は多かったのだが、何分BPFは設計が古い。レジスタは2個で32bit、命令セットはatomic compare exchangeのようなモダンなプロセッサーに搭載されている命令がない。 そのためeBPF(extended BPF)が設計された。レジスタは10個
GNU Debugger Adding eBPF Debugging Support Written by Michael Larabel in GNU on 5 August 2020 at 12:08 AM EDT. Add A Comment The GNU Debugger (GDB) has merged initial support for debugging of eBPF code that is traditionally consumed by the Linux kernel as part of this in-kernel special purpose virtual machine. Oracle engineer Jose Marchesi contributed the new target of (e)BPF for basic debugging a
この記事はRed Hat DeveloperのIntroducing debuginfod, the elfutils debuginfo serverを、許可をうけて翻訳したものです。debuginfodは現在活発に開発中のソフトウェアで、2020年1月時点では elfutils へのマージが完了し、Fedora 31には含まれましたがまだRHELには含まれていません。 :::By Aaron Merey October 14, 2019 ::: バグを避けることはできないので、開発者は Systemtap や GDB などのデバッグツールへ素早くかつ簡単にアクセスできる必要があります。これらのツールは典型的にはDWARF(Debugging With Attributed Record Formats)を含むdebuginfoやソースファイルに依存します。これらのリソースへのアクセスは
概要 Linuxカーネルの脆弱性はよく見つかるので、たまにLinuxカーネルのデバッグしたいときがあると思います。printkデバッグでも良いんですが、いちいちビルドするの面倒だし良い感じにステップ実行できれば良いのにと思っていました。 思うだけで何一つ行動に移していなかったのですが、今回SACK Panicの脆弱性調査のために気合い入れてデバッグ環境を作ったので残しておきます。 環境はVagrantで作っていて、デバッガはkgdbを使っています。正直細かい話はよく分かってないのでカーネル詳しい方々の説明を見たほうが良いですが、とりあえず動かしたければ役に立つかもしれません。 カーネルのデバッグなんかググればアホほど記事あるだろうと思ってたのですが、意外とステップ実行頑張ってる人は少なさそうに見えました。なので綺麗にステップ実行できるようになるまでにもそこそこ苦労しました。 環境 ホスト環
この記事はLinux Advent Calendar 2018の1日目ですΣ(゚∀゚ノ)ノキャー イントロ ほんとは別の内容にしようと思ってたのですが、進めてる途中でカーネルのデバッグをするハメになったのでカーネルデバッグをネタにしてみました。カーネルのデバッグと言っても普通のデバッグと変わらないよね〜というところがわかると思います。(`・ω・´)<コワクナイヨー デバッグの環境としてはlibvirt(qemu)で動いてるゲスト環境にホスト側からgdbでデバッグする感じです。ディストリビューションはFedora 29です。デバッグするカーネルはFedoraのカーネルで4.19.2-300.fc29.x86_64です。 テストコード テストコードは↓です。これはdebugfsのディレクトリ(大概は/sys/kernel/debug/だと思います)にopen-testってファイルを作って、その
11.2 GDBを使用してデバッグする プログラムを開発するにあたって開発者は度々デバッグコードを書く必要があります。Go言語は、PHPやPythonといった動的な言語のようにコンパイラを必要とせず修正を行うだけで直接出力し、動的に実行環境下でデータを出力できるわけではありません。当然Go言語もPrintlnのようにデータを出力することでデバッグすることはできますが、毎回再コンパイルする必要があります。これは非常に面倒くさいことです。Pythonではpdb/ipdbのようなツールによってデバッグを行うことができますし、Javascriptにも似たようなツールがあります。これらのツールはどれも動的に変数情報を表示させることや、ステップ実行ができます。我々はGDBを使ってデバッグすることができます。ではこの節ではどのようにしてGDBによってGoプログラムをデバッグするのかご紹介しましょう。 G
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
@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日
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く