【求解】调试ubicom的板子，内核panic了

qihaimou

在ubicom架构处理器下运行gdbserver，内核panic了，将init进程杀死，
下面信息，不知道怎么分析，有经验的大虾们帮忙下该怎么分析。

/nfs/ubicom # ./gdbserver 192.168.111.56:2345 ./stack_test
gdbse
Process init (pid: 1)
text = 0x47000000-0x470df394  data = 0x47b40394-0x47b6d8c0
bss = 0x47b6d8c0-0x47b80000   user-stack = 0x47b9fe90

User Trap: Causes: 0x00001400
        decode: 00000400 inst range error
        decode: 00001000 dst range error
regs: 406f7f50, tid: 0
pc: 740025e4, previous_pc: 47a1257c

Data registers
D00: 0000033e, D01: 00000000, D02: 00000000, D03: 00000000,
D04: 00000000, D05: 81010100, D06: 00000000, D07: 00000000,
D08: 00000072, D09: 00000007, D10: 00000000, D11: 00000000,
D12: 0000030b, D13: 47b1cef4, D14: 00000053, D15: fffffffe,

Address registers
A00: 47be3420, A01: 47b66c60, A02: 00000000, A03: 00000000,
A04: 40119748, A05: 3ffc00e0, A06: 47b9fe94, A07: 47b9fc94,

acc0: 00000018-00000000, acc1: 00989680-00000000
mac_rc16: 00000000, source3: 47b3d614
inst_cnt: 1ef011df, csr: 00000000
int_mask0: 00000000, int_mask1: 00000000
IRange0: en:00000fff, range: 3ffc0000-47fffffc
IRange1: en:00000fff, range: 3ffc0030-3ffc0168
IRange2: en:00000fff, range: 40386000-47fffffc
IRange3: en:00000fff, range: 40400010-40400014
DRange0: en:00000fff, range: 00000800-02009ffc
DRange1: en:00000fff, range: 3ffc0000-47fffffc
DRange2: en:00000fff, range: 40384000-47fffffc
DRange3: en:00000fff, range: 40004300-400ffffc
DRange4: en:00000000, range: 00000000-fffffffc
frame_type: 2, nesting_level: 0, thread_type 1

Starting backtrace: PID 1 'init'
  User Stack (fdpic):
Start of vma list
End of vma list
    code[0x40100000-0x48000000]
    stack[0x47b9fc94-0x47b9fe90]
  CALL && CALLI on stack:
    0x47a54f14, 0x470d7d48,
--- End Trap ---
rver: linux_test_for_tracefork: failed to kill second child
Process ./stack_test created; pid = 831
Listening on port 2345
Kernel panic - not syncing: Attempted to kill init!

zykjz

为楼主打气
高手在哪里！！

qihaimou

额，这个问题我已经忘了，不过上面内核打印的trap信息是由于应用程序段错误导致的User Trap: Causes: 0x00001400。但内核panic是没有看到打印信息，所以也无法知道问题所在。另外上面的A05寄存器是保存函数调用前的下一条指令的地址，相当于x86架构下的ip寄存器。

linuxfellow

回复 1# qihaimou

有了core dump, 查错就是相对容易：

CALL && CALLI on stack:
    0x47a54f14, 0x470d7d48,

问题出在函数0x47a54f14，这个函数被前一个函数0x470d7d48。从你的application.map里找这两个地址分别在哪两个function里， 这样你就知道是那个函数被谁调用时出了问题。你的情况是： 函数0x470d7d48 运行到47a1257c时出错： 你就把断点设在函数47a1257c，单步跟踪。
如果每次运行到这里都出错，问题马上就解决了。如果问题运行很久才出现，单步跟踪很长时间问题都不出现，那你就必须有能设置条件断点的跟踪器，不然你就对照代码拍脑袋分析各种可能的情况。core dump已经给了你足够的信息了