Linux driver Debugging--Oops information analysis of segment error

Linux driver Debugging--Oops information analysis of segment error http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=29401328&id=4923447

1. Analyze Coredump printing Information

2. Identify the function that has the error

See the function and the PC where the error occurred

PC is at segment_test_open+0x14/0x1c [Segdrv]

Look at the PC value:

PC: [<7f000014>] LR: [<800d958c>] psr:20070013

See BackTrace:

[<7f000014>] (Segment_test_open [Segdrv]) from [<800d958c>] (chrdev_open+0xa4/0x178)
[<800d958c>] (Chrdev_open) from [<800d3e1c>] (do_dentry_open.isra.17+0x110/0x294)

First, directly determine the function that the error occurred
See this phrase "PC is at segment_test_open+0x14/0x1c [Segdrv]"We are most concerned about the PC value when an error occurs because it is an error
The address of the instruction, where we can see that the error occurred at the Segment_test_open of the function, 0x1c represents the total length of the function (assembly code)

Second, according to the PC value to determine the function of the error
Sometimes it doesn't tell you directly which function is happening, but instead tells you the value of the PC.

If the error function that occurs is a driver module

# arm-none-linux-gnueabi-objdump-d First_drv.ko > First_drv.dis

If the error function that occurs is the kernel of
this time is similar to what happened in the module, but the entire kernel is disassembled:
# arm-none-linux-gnueabi-objdump-d vmlinux > Vmlinux.dis

Linux driver Debugging--Oops information analysis of segment error