我的博客

根据oops信息，找到出问题的函数xxx_func，以及对应的xxx文件根据gdb和xxx.o文件；使用《 disassemble /m xxx_func 》来反汇编出代码，已经代码对应的汇编码；注意xxx_func若有内联函数的话，可能显示不全，建议不要用内联函数，而直接用代码替换根据oops信息找到出问题的pc指针，根据这个pc相对于xxx_func的偏移，找到出问题的代码行，代码下面会有汇编码，这个汇编的寄存器，又可以在oops信息里找到寄存器的快照(汇编不懂就用ai解释下)

在 Linux 驱动开发中，是用于为设备创建单个属性文件的函数。如果你需要为一个设备创建多个属性文件（即多个sysfs属性），可以通过多次调用来实现。不过，为了提高代码的可读性和维护性，Linux 内核提供了一种更高效的方式——使用机制来批量定义和注册多个属性文件。

SquashFS是一种只读的压缩文件系统，主要用于嵌入式系统、Live CD/DVD 和其他需要高效存储和快速访问只读数据的应用场景。它通过压缩文件和目录结构来减少存储空间的需求，并且支持快速随机访问。OverlayFS是一种联合文件系统（Union Filesystem），它可以将多个目录层叠在一起形成一个新的虚拟文件系统。这种技术使得在不修改底层文件系统的情况下进行读写操作成为可能。OverlayFS 在容器技术、Live 系统和嵌入式设备中得到了广泛应用。

无论是去驱动编译，还是应用编译，本质上都是用gcc这个工具，后面跟不同的参数来完成。

简单的说，出现内核奔溃，我们可以通过串口日志提供的信息；使用gdb反汇编出问题函数所在的文件，然后使用《disassemble /m 函数名》查看具体函数的源码和汇编码；这样能直观的看到源代码对应的汇编码干了什么；再根据串口日志的寄存器信息，查看当时寄存器的值，就能对上当时的参数，和变量的值。

crng_finalize_init后出现死锁。

影响代码如下：of_property_read_u32返回0是找到节点里的属性了，返回负数是没找到；而且没对gpio_request做返回判断，如果有冲突的情况，这个地方还设置了gpio0为输入---那就异常了，该输出的gpio，被异常设置成了输入。但是后面其他驱动，使用of_property_read_u32获取设备树节点的属性时，没去判断返回值；而直接使用参数返回的0，导致gpio-0又被设置成了输入。修改如下：所以对接口的返回值做判断很重要，能避免一些奇葩的bug。正常的如下，gpio显示为输出。

先动态分配内存，存放kobject对象，并调用kobject_init完成目录属性文件的操作接口设置，设置kobject对象的ktype为dynamic_kobj_ktype，设置dynamic_kobj_ktype中的sysfs_ops变量为kobj_sysfs_ops，设置kobj_sysfs_ops为show变量为kobj_attr_show，store变量为kobj_attr_store，这就是该kobject对象默认的属性文件操作接口,分别对应着读写操作。就会在sysfs生成如下节点，便于操作。

在用户层，通过一个进程来创建一个netlink，这个应用程序可以是mdev,udev或者openwrt的procd,这三种方式都是基于netlink来管理热插拔的，比如procd通过NETLINK_KOBJECT_UEVENT参数来通过socket系统调用创建一个fd来与内核的netlink交互数据，内核上报uevent被这个进程接受后，然后调用/etc/hotplug.d/的各脚本来执行热插拔操作。这是热插拔触后，触发的事件给应用层，然后执行的脚本，跟上面的信息是对上的。比如插拔sim卡会打印如下信息。

addr2line定位。addr2line定位。

上面这个函数我们可以看到，会调用kprobe的pre_handler和post_handler，这两个函数被我们实现好，装填进kprobe,并用register_kprobe注册到kprobe子系统；kprobe其实就是将某个要检测的指令备份，再替换成int3(x86)或者未定义指令(arm)来触发异常，再调用对应体系的异常处理函数来执行我们自定义的hook，执行完我们自定义的hook,再将备份的指令放回原来的位置继续往下执行。替换成未定义指令后，就会触发的未定义指令异常处理函数。

【代码】qemu使用简介。