c – 调试令人讨厌的SIGILL崩溃：文本段损坏

Ours是一个运行 Linux的基于PowerPC的嵌入式系统.我们遇到了随机的SIGILL崩溃,可以看到各种各样的应用程序.崩溃的根本原因是要执行的指令归零.这表示驻留在内存中的文本段损坏.由于文本段以只读方式加载,因此应用程序无法破坏它.所以我怀疑一些常见的子系统(DMA？)导致这种腐败.由于问题需要数天才能重现(由于SIGILL而崩溃),因此很难进行调查.首先,我希望能够知道任何应用程序的文本段是否以及何时被破坏.
我查看了堆栈跟踪和所有指针,寄存器是正确的.
你们有什么建议我怎么办呢？

一些信息：
Linux 3.12.19-rt30#1 SMP Fri Mar 11 01:31:24 IST 2016 ppc64 GNU / Linux

(gdb)bt
xxx中的0 0x10457dc0

拆卸输出：
=> 0x10457dc0< 80>：mr r1,r11
0x10457dc4< 84>：blr 预期在地址0x10457dc0：0x7d615b78的指令
捕获SIGILL 0x10457dc0：0x00000000后找到的指令

(gdb)维护信息部分
0x10006c60-> 0x106cecac at 0x00006c60：.text ALLOC LOAD READONLY CODE HAS_CONTENTS

预期(来自应用程序二进制文件)：
(gdb)x / 32 0x10457da0
0x10457da0：0x913e0000 0x4bff4f5d 0x397f0020 0x800b0004
0x10457db0：0x83abfff4 0x83cbfff8 0x7c0803a6 0x83ebfffc
0x10457dc0：0x7d615b78 0x4e800020 0x7c7d1b78 0x7fc3f378
0x10457dd0：0x4bcd8be5 0x7fa3eb78 0x4857e109 0x9421fff0

实际(处理SIGILL并转储附近的内存位置后)：
错误指令地址：0x10457dc0
0x10457da0：0x913E0000
0x10457db0：0x83ABFFF4
=> 0x10457dc0：0x00000000
0x10457dd0：0x4BCD8BE5
0x10457de0：0x93E1000C

编辑：
我们的一个主要原因是腐败总是发生在以0xdc0结尾的偏移处.
对于例如
错误指令地址：0x10653dc0<<在捕获SIGILL之后由@R_352_9616@程序打印
错误指令地址：0x1000ddc0<<在捕获SIGILL之后由@R_352_9616@程序打印
flash_erase [8557]：未处理的信号4在0fed6dc0 nip 0fed6dc0 lr 0fed6dac code 30001
nandwrite [8561]：未处理的信号4在0fed6dc0 nip 0fed6dc0 lr 0fed6dac code 30001
awk [4448]：未处理的信号4在0fe09dc0 nip 0fe09dc0 lr 0fe09dbc code 30001
awk [16002]：未处理的信号4在0fe09dc0 nip 0fe09dc0 lr 0fe09dbc代码30001
getStats [20670]：0fecfdc0处的未处理信号4 nip 0fecfdc0 lr 0fecfdbc code 30001
expr [27923]：未处理的信号4在0fe74dc0 nip 0fe74dc0 lr 0fe74dc0 code 30001

编辑2：另一个领导是腐败总是发生在物理帧号0x00a4d.我想,如果PAGE_SIZE为4096,则会转换为0x00A4DDC0的物理地址.我们怀疑我们的几个内核驱动程序并进一步调查.是否有更好的想法(比如放置硬件观察点)哪个更有效？如下所示,KASAN怎么样？

任何帮助表示赞赏.谢谢.