For kernel disassembly, the source file is displayed at the same time.

I wrote a UART test driver in the platform architecture. It was strange that the driver could not be detached due to a problem during uninstallation,

The rmmod used by the user space will eventually call syscall_define2 (delete_module, const char _ User *, name_user, unsigned int, flags) in kernel/module. C)

1. Find the module by the module name displayed by lsmod

MoD = find_module (name );
If (! MoD ){
Ret =-enoent;
Printk ("lccdandeion we cant find mod \ n ");
Goto out ;}

2. check whether any module depends on this module.

If (! List_empty (& mod-> modules_which_use_me )){
/* Other modules depend on us: Get rid of them first .*/
Printk ("lccdandeion there are modules using me \ n ");
Ret =-ewouldblock;
Goto out;
}
3. Check whether the module is alive

/* If it has an init func, it must have an exit func to unload */
If (mod-> init &&! Mod-> Exit)
{
Forced = try_force_unload (flags );
If (! Forced ){
/* This module can't be removed */
Ret =-ebusy;
Goto out;
}
}
4. If the parameters passed by the user space require forced uninstallation, uninstall the module (select the module that can be forcibly uninstalled during kernel compilation) and check whether the reference count of the module is zero (not zero, wait until the reference count is zero)

/* Never wait if forced .*/
If (! Forced & module_refcount (MOD )! = 0)
{
Printk ("lccdandlion wait for zero refcount \ n ");
Wait_for_zero_refcount (MOD );
Printk ("lccdandelion wait end \ n ");
}
5,

/* Final destruction now noone is using it .*/
If (mod-> exit! = NULL)
{
Printk ("lccdandeion did we blocked \ n ");
Mod-> exit ();
}
The write UART driver test crashes when mod-> exit () is called.

How can we locate problems in the face of panic?

1. Google

2. Use panic information and disassemble the kernel

For 2:

Kbuild_cflags: =-wall-wundef-wstrict-prototype in makefile at the top layer of the source code tree ....

Add kbuild_cflags: =-g-wall-wunde-wstrict-Prototype

The generated kernel will contain debugging information. The 611 kernel source code does not support GDB, but we can disassemble it,

Unicore32-linux-objdump-Dz-s vmlinux> Linux. Dump

Based on the panic information, you can locate several function call paths when the final error is reported, pile up in the function, and locate the problem step by step, although 611 is somewhat closed, however, Google can generally find problems with the core of the kernel.

 

Although the problem is solved, the panic information is still strange. in panic, the PC value is no longer in kernel space ????!!!!