36. Linux driver debugging-locate the error code line based on oops, 36. linuxoops

36. Linux driver debugging-locate the error code line based on oops, 36. linuxoops

1. When a drive error occurs, for example, if the accessed memory address is invalid, a large string of oops will be printed.

1.1 Use LED driver as an Example

Block ioremap () in the open () function and directlyUse physical addressGPIOF, as shown in:

 

1.2 then, after compiling and loading 26th_segmentfault and executing the test program, the kernel prints out oops, as shown in:

 

 

2. Next, we will analyze oops:

Unable to handle kernel paging request at virtual address 56000050 // virtual address 5621350pgd = c3850000 [56000050] * pgd = 00000000 Internal error: Oops: 5 [#1] // internal error oopsModules linked in: 26th_segmentfault // indicates that an internal error occurs in the 26th_segmentfault.ko driver module. CPU: 0 Not tainted (2.6.22.6 #2) PC is at first_drv_open + 0x78/0 x12c [26th_segmentfault] // PC value: the last address of the program running successfully, which is located in the first_drv_open () function. The offset value is 0x78, the total function size 0x12cLR is at 0xc0365ed8 // LR value/* value of each register when an error occurs */pc: [<bf000078>] lr: [<c0365ed8>] psr: 80000013sp: c3fcbe80 ip: c0365ed8 fp: c3fcbe94r10: 00000000 r9: c3fca000 r8: c04df960r7: 00000000 r6: 00000000 r5: bf000de4 r4: 201710000r3: 00000000 r2: 56000050 r1: 00000001 r0: 00000052 Flags: Nzcv IRQs on FIQs on Mode SVC_32 Segment userControl: c000717f Table: 33850000 DAC: 00000015 Process 26th_segmentfau (pid: 813, stack limit = 0xc3fca258) // when an error occurs, the process name is failed: (0xc3fcbe80 to 0xc3fcc000) // stack information be80: c06d7660 c3e880c0 c3fcbebc c3fcbe98 running bf000010 00000000 failed: commandid without c3fb9534 c3fcbee4 running c0089e48 failed: c04df960 running 00000003 ffffff9c running c380a000 c3fcbefc running: c0089f64 running 00000000 00000002 running too large: Running c3fb9534 running 00000000 00000000 c00001000 00000101 running 0001bf20: 00000000 c3fca000 running without c380a000 running: 20171000000000003 00000000 000000000002 be84ce38 cost: 2017c008a2f4 c0089f88 00008588 be84ce84 00008718 0000877c 00000005bf80: 00004013365c 0000000000000000000000000000 cost: describe84ce84 00008718 be84ce30 00000002 be84ce38 cost: be84ce84 00008718 da-877c 00000003 00008588 00000000 4013365c 5E: 00000000 be84ce28 108266c 400c98e0 60000010 be84ce30 30002031 30002431 Backtrace: // trace information [<bf000000>] (Listen + 0x0/0x12c [comment]) from [<c008d888>] (chrdev_open + 0x14c/0x164) r5: c3e880c0 r4: c06d7660 [<c008d73c>] (chrdev_open + 0x0/0x164) from [<c0089e48>] (_ dentry_open + 0x100/0 x1e8) r8: c3fb9534 r7: c0474e20 r6: c008d73c r5: c3e880c0 r4: c04df960 [<c0089d48>] (_ dentry_open + 0x0/0x1e8) from [<c0089f64>] (nameidata_to_filp + 0x34/0x48) [<c0089f30>] (nameidata_to_filp + 0x0/0x48) from [<c0089fb8>] (do_filp_open + 0x40/0x48) r4: 00000002 [<c0089f78>] (do_filp_open + 0x0/0x48) from [<c008a2f4>] (do_sys_open + 0x54/0 xe4) r5: be84ce38 r4: 00000002 [<c008a2a0>] (do_sys_open + 0x0/0xe4) from [<c008a3a8>] (sys_open + 0x24/0x28) [<c008a384>] (sys_open + 0x0/0x28) from [<c002bea0>] (latency + 0x0/0x2c) Code: bf000094 bf0000b4 bf0000d4 e5952000 (e5923000) Segmentation fault

2.1 aboveBacktracing information, indicatingThe entire function call Process

For example, the above backtracking information indicates:

• Sys_open ()-> do_sys_open ()-> do_filp_open ()-> nameidata_to_filp ()-> chrdev_open ()-> first_drv_open ();

The final error is first_drv_open ();

 If no tracing information is displayed in the kernel, the function call process is not printed. You can modify the. config file of the kernel and add:

// CONFIG_FRAME_POINTER, indicating the frame pointer, expressed in the fp register

In the kernel, the fp register is used to record the operation location of the function and coexist in the stack. When a problem occurs, the fp register is called out from the stack to view the call relationship of the function, you can see the tracing information.

(PS: If this parameter is not configured, you can use the stack to analyze the function call process. It will be analyzed in the next chapter)

2.2Some kernel environments are different, oppsOr the above information may not be printed:

Modules linked in: 26th_segmentfaultPC is at first_drv_open+0x78/0x12c [26th_segmentfault]

The related information is simply printed on the PC value, so it cannot be known whether it is a problem with the driver module or a problem with the built-in functions of the kernel?

So the most important content in oops is this section:Pc: [<bf000078>]

 

2.3So how to determine,This PCFunction with the value address in the kernel,Or the driver module we load?

A:

The "vi System. map to view, this file stores all the virtual address ing (symbols, functions) in the kernel, such as the kernel function root_dev_setup ():

 

The virtual address of the kernel is c0004000 ~ C03cebf4

So,Pc ValueBf000078The address value of the driver module.

 

2.4When multiple drivers are loaded,How to differentiate PCsWhich driver is the function's address value?

A: You can view it using/proc/kallsyms:

# Cat/proc/kallsyms // (kernel all symbols) view the address values of all kernel labels (including kernel functions, loaded driver functions, and variable symbols)

Or:

# Cat/proc/kallsyms>/kallsyms.txt // Add the address value to kallsyms.txt

As shown in, find the pc value in kallsyms.txt.Bf000078Located in the bf000000 + 0x78 of the first_drv_open () function in the 26th_segmentfault driver

 

2.5 then generate disassembly for the driver:

Arm-linux-objdump-D 26th_segmentfault.ko> 26th_segmentfault.dis // Disassembly

 

2.6Open disassembly:

As shown in, the left side is kallsyms.txt, and the right side is 26th_segmentfault.dis disassembly.

 

Obviously, the pc value bf000078 is located at the 78 address of the disassembly:

Disassembly of section. text ://. the start address of the text segment is 0x0000000000 <first_drv_open>: 38: e59fc0e8 ldr ip, [pc, #232]; 128 <. text + 0x128> // ip =. text section + content in 0x128 ...... 50: e585c000 str ip, [r5] // r5 =. text section + content in 0x128 ...... 74: e5952000 ldr r2, [r5] // r2 =. text Segment + 0x128 content 78: e5923000 ldr r3, [r2] // r3 =. text + 0x128 content 7c: e3c33c3f bic r3, r3, #16128; 0x3f00 // clear bit8 ~ 13 ...... 128: 56000050 undefined //. text Segment + content in 0x128 = 0x56000050

(PS: Where, the pc value 78 indicates the last successful address, so the error address is on 78 + 4)

Therefore, the error is found under the first_drv_open () function:

 

3. If the wrong driver is located in the kernel address value

3.1Or26th_segmentfault.c:

# Cp 26th_segmentfault.c/linux-2.6.22.6/drivers/char // copy the problematic driver to the character driver directory

 

#vi Makefile

Add:

Obj-y + =26th_segmentfault.o // y: Put the driver into the kernel.

 

3.2 then make uImage loads the new kernel, and then runs the test program to print the opps Information

3.3 run the following command in the root directory of the kernel source code:

# arm-none-linux-gnueabi-objdump -D vmlinux > vmlinux.dis

Disassemble the entire kernel, vmlinux: Uncompressed Kernel

3.4 vi vmlinux. dis, and then find the address directly through the PC value of oops Information

 

The next chapter analyzes the function call process through stack information ~