0

gdbLinux カーネルの FIQ ハンドラーでデバッガーを取得して期待どおりに動作させることができません。FIQ トリガーの条件を設定するドライバー コードには問題なくトリガーできますが、FIQ ではトリガーできません。

OlimexのARM-USB-TINY-Hデバッガー +imx233-SJTAGコンバーター (ボードにはパラレル JTAG 用のピンがありません) を使用して、i.mx233 ボードをデバッグしています。

私はgdb 7.5.1buildrootでコンパイルしており、openocd 0.6.1Ubuntuリポジトリから来ています。openocd を起動します。

# openocd -f olimex-arm-usb-tiny-h.cfg -f imx233.cfg

Open On-Chip Debugger 0.6.1 (2012-12-06-17:15)
....
Info : only one transport option; autoselect 'jtag'
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
adapter speed: 800 kHz
dcc downloads are enabled
fast memory access is enabled
Info : max TCK change to: 30000 kHz
Info : clock speed 789 kHz
Info : JTAG tap: imx23.cpu tap/device found: 0x079264f3 (mfg: 0x279, part: 0x7926, ver: 0x0)
Info : Embedded ICE version 6
Info : imx23.cpu: hardware has 2 breakpoint/watchpoint units

ブレークポイントの開始gdbと設定:

# arm-buildroot-linux-uclibcgnueabi-gdb vmlinux
....
target remote :3333
Remote debugging using :3333
0x00000000 in ?? ()
(gdb) monitor halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0xc0019024
MMU: enabled, D-Cache: enabled, I-Cache: disabled
(gdb) hbreak mydriver_userland_write
Hardware assisted breakpoint 1 at 0xc02da930: file drivers/misc/mydriver.c, line 309.
(gdb) c
Continuing.

この時点で、ユーザーランドからドライバーにメッセージを送信するたびに、gdb が喜んでトリガーされます。

Breakpoint 1, mydriver_userland_write (filp=0xc2cb81c0, buf=0x19d8600 "1\n\235\001t", count=2, f_pos=0xc2cb3f88) at drivers/misc/mydriver.c:309
309                       size_t count, loff_t *f_pos) {

ユーザーランドからの情報を処理した後、FIQ がトリガーされる条件を初期化し、戻ります。ではgdb、FIQ のブレークポイントを設定しました。(60行目は基本的に割り込みフラグクリア後の4番目のアセンブラ命令です)

## Enable catching for FIQ vectors
(gdb) monitor arm9 vector_catch fiq
reset: don't catch
undef: don't catch
swi: don't catch
pabt: don't catch
dabt: don't catch
irq: don't catch
fiq: catch

## setup the breakpoint
(gdb) hbreak myfiq_handler.S:60
Hardware assisted breakpoint 1 at 0xc02db040: file     drivers/misc/myfiq_handler.S, line 60.
(gdb) c
Continuing.

すべてのセットアップが完了した後、FIQ 処理につながる条件をトリガーすると、ここで奇妙な結果が発生します。

Program received signal SIGTRAP, Trace/breakpoint trap.
0xffff001c in ?? ()

私はこの時点で本当に何もできません：

## Try to see call trace
(gdb) bt
#0  0xffff001c in ?? ()

## Try stepping
(gdb) step
Cannot find bounds of current function
(gdb) next
Cannot find bounds of current function

monitor reg次のような登録状態を示していますhttp://paste.ubuntu.com/6113942/ vmlinux マップ ファイルを見ると、PC はファイルの最後の 4 行を文字通り指しています。

ffe5095d A __crc_groups_free
fff3672c A __crc_directly_mappable_cdev_bdi
ffffe9f5 A __crc_cfg80211_wext_giwfrag
     w __crc_softirq_work_list

コマンドを使用するstepiと、実行全体がハングしているように見えます。

私はまだ使用方法を学んgdbでいるので、今どこで問題を探すべきか本当にわかりません..どんな提案も大歓迎です!

4

1 に答える 1

1

FIQルーチンは、ベクタ テーブルの末尾にコピーされます。ARMベクトル テーブルのレイアウトは、

  1. リセット
  2. 未定義命令
  3. ソフトウェア割り込み (SWI)
  4. プリフェッチ アボート
  5. データ中止
  6. 4バイトホール
  7. IRQ (通常割り込み)
  8. FIQ (高速割り込み)。

バンクされたレジスタと同様にr8-r14、このFIQモードは実行をアドレス0x1c (およびテーブル オフセット) に直接渡します。他のすべての例外は通常、分岐命令を実行します。ただし、FIQの場合、分岐する必要はありません。つまり、アセンブラー ルーチンを直接実行できます。

set_fiq_handler()Linux のfiq.cのルーチンを参照してください。GDBはこの再配置を認識せず、元のアドレスにブレークポイントを配置します。注意点として、初期FIQルーチンはPC 相対でなければなりません。そうしないと、実行されません。GDBでは、最初の命令b 0xffff001cでブレークポイントを設定するために使用できます。FIQ

その他の例外とベクタ テーブルの定義は、命令と同様にファイルの下部にあるentry-armv.Sにあり、ルーチンによって上書きされます。カーネルのリンカー スクリプトであるvmlinux.lds.Sも参照してください。ルーチンのサイズとして0x1000-0x1cのスペースがあります。__vectors_startW(b) vector_fiqFIQ

于 2013-09-16T13:59:31.850 に答える