Linux kernel gdb&x2B；arm调试器无法在linux驱动程序中触发为FIQ

我很难让调试器和

gdb

与Linux内核中的FIQ处理程序一起正常工作。它可以对设置FIQ触发条件的驱动程序代码进行精细触发，但不适用于FIQ

我正在从Olimex使用

ARM-USB-TINY-H

debugger+

imx233 SJTAG

转换器（该板没有用于并行JTAG的引脚）来调试I.mx233板

我正在用buildroot编译

gdb7.5.1

，而

openocd0.6.1

来自Ubuntu存储库。我启动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.

现在，当我从userland向驱动程序发送消息时，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) {

在处理来自userland的信息之后，我初始化了触发FIQ的条件，然后返回。 在

gdb

中，我为FIQ设置了断点。（第60行基本上是清除中断标志后的第四条汇编指令）

现在，设置完毕后，我触发导致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

这样显示寄存器状态 如果我查看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

，所以我现在真的不知道该去哪里寻找问题。。欢迎提出任何建议

FIQ例程被复制到向量表的末尾。ARM向量表的布局如下：

重置

未定义指令

软件中断（SWI）

预取中止

数据中止

4字节孔

IRQ（正常中断）

FIQ（快速中断）

与存储寄存器一样，

r8-r14

，

FIQ

模式将执行直接交给地址0x1c（加上表偏移量）。所有其他异常通常都会执行分支指令。但是，对于

FIQ

，不需要分支，这意味着您的汇编程序例程可以直接执行

请参阅Linux中的例程

set\u fiq\u handler（）

。您的GDB将不知道此重新定位，并将在原始地址处放置一个断点。作为警告，初始的

FIQ

例程必须是PC-relative，否则将不执行。在GDB中，您可以使用

b 0xffff001c

在初始

FIQ

指令处设置断点

---

其他异常和向量表定义位于文件底部附近，使用

W（b）vector\u fiq

指令作为

\uuuu vectors\u start

，该指令将被例程重写。另请参见内核的链接器脚本。作为

FIQ

例程的大小，您有一个0x1000-0x1c的空间。

实际上，您的代码可能不会与PC相关，因为代码的副本（以及

。data

，

。rodata

）存在于原始地址。再次感谢您的回复，无噪音。所以，我想知道为什么会这样？我的意思是我最初将bp设置为

0xc02db040

。。是不是因为我告诉gdb

监控arm9矢量_捕获fiq

？很抱歉为同一个问题引入另一个元素，但如果我将bp设置为

0xffff001c

，我是否仍然可以以某种方式使ddd显示fiq代码（来自myfiq_handler.S）并能够更好地可视化进度？由于某些原因，我仍然无法在断点后继续执行。。我似乎遇到了

if（find_pc_partial_function（pc，&name，&tp->control.step_range_start，&tp->control.step_range_end）==0）

在

gdb/infcmd.c

函数

step_once

中我认为

gdb

在抱怨你的代码是它不知道的；关于

find\u pc\u partial…

。您的初始断点可能会起作用，因为您的代码可能会跳回旧的断点，或者您有其他导致断点的工具集。我会在常规模式下调试；我从未发现一个调试器对ISR有效。您可以设置

fiq

寄存器，并使用

/proc

或

/sys

write调用一个函数，该函数在内核空间中切换到

fiq

模式，并执行测试中的例程。当

FIQ

实际处于激活状态时，这应将代码差异降至最低。即使您调试CPU，SOC上仍有不同的硬件未得到维护。某些DMA硬件可能会执行异常操作，例如当您长时间暂停执行时。用作切换模式的模板。

ffe5095d A __crc_groups_free
fff3672c A __crc_directly_mappable_cdev_bdi
ffffe9f5 A __crc_cfg80211_wext_giwfrag
     w __crc_softirq_work_list