肺炎疫情憋在家里,总结一下很久之前的学习笔记,先说说系统开发工程都需要的内核调试方面。主要是结合以前的项目调试经验和笔记,欢迎大家补充,还记得以前从0 开始写一个bootloader,把一个linux 系统在三星s3c2410上跑起来,基本就是使用printk 来调试的。
上面这一段就是一个典型的IC 原厂的工程师在最开始把linux移植到芯片上的bootargs,是bootloader 启动时传给kenerl的参数,因为一个芯片从来没有跑过linux,基本从0开始,根据经验,在没有仿真器的情况下,是完全可以把linux跑起来。源码级调试的需求在linux工程上是非常小的,linux主要是靠经验及printk去推测代码路径,只有极少数情况才会用到仿真器,比如硬件有什么故障,总线hang死了,CPU模式切换,内存错了等非常底层问题才可能用到仿真器。当然这些小概率的问题没仿真器是没法调试,因为代码跟不进去,不过这种情况通常是IC原厂的工程师会做的事情。
early printk(early console) 实现及initcall
在我们820a 平台上,这些文件是非常lowlevel的打印语句(uart driver驱动子系统起来之前),是通过汇编语言实现的非常简单的打印语句,这些语句可以在linux非常早期就可以使用,比如刚把linux 解压完,“uncompress linux”就可以打印出来了。
Kenel config如下:
所以在调试linux早期阶段,会利用这种lowlevel的手段调用打印跟踪启动过程,之后linux就会调用到很多初始化init function。 初始化也有不同的level,其中很多也是驱动的初始化,Linux使用一个for循环把所有函数调用一段,他不是手工的去掉,他是把每个初始化函数的指针放在一个特殊的数据段里面,再利用一个for循环取出这个数据段的第一个函数取出来,一直调用到最后一个指针。这个过程可能有几百个initcall,这些initcall有些是linux自带的,有些是我们自己写的,所以这个过程中initclal可能会直接挂掉,需要有一个办法在开机时就打印出来,linux有一个方式是initccall debug,通常我们再bootarges 中传入一个initcall_debug,linux就会把每个初始化函数什么时候调用的,及返回是什么全部打印出来,如果某个calling打印之后就没有打印了,说明这个calling就卡住了。
printk虽然非常简单,但是作为一个linux工程师不能一上来就直接一个printk,显得非常不专业,专业的linux工程师一般调用printk的两个变体,一个是dev_xxx,pr_xxx, 我们一般在驱动中调用dev_xxx(dev_info, dev_err 等),这个会自动给你打印增加设备的打印前缀。这样就一目了然,不会混乱,比如你是spi,就会打印spi***之类的。有时候我们仅仅增加一个模块(非设备驱动中),这时候我们可以使用pr_XXX(pr_info, pr_err...).这个时候我们可以在模块最前面定义一个pr_fmt, 这个整个模块的pr打印自动会添加签名pr_fmt定义的前缀
还有一种情况在工作中遇到比较多,就是在打印中加上自己的名字,尽量针对需要的打印的特点,功能,模块添加打印信息,加个名字显得很怪,搞不好还要遗臭万年,嘿嘿。
Linux printk 比我们想象的要好用,printk 这个函数不像printf,因为printk不会引起睡眠,在软中断,中断,spinlock里面等,基本所有的上下文都可以调用。
当然,调得太多,也会让系统变慢,所以我们有时候需要基于linux本身的理解,防止影响系统,所以一个牛x的工程能够在正确的位置加printk。
Linux内部函数调用有时候是非常深的,我们有时候直接在最底层函数加一个dump_stack()或者使用warn_on(1) ,内核调到这里就会把调用栈打印出来。
源码级调试
工程上通常去淘宝买个jtag 仿真器就可以了,插根网线或者usb就可以gdb 调试了。Arm官方的是DS-5,这个东西功能很强大可以结合eclipse 调试,但是对于我们来说,图形界面再强大,还是基于对linux代码的理解去调试。
通常可以利用qemu 或者仿真器连接板子,再使用gdb vmlinux 启动,使用target remote ip:port 连接目标板,这样就可以进行源码调试了。
按下ctr+x 抬起来按下a,就分裂两个窗口,一个源码,一个命令,这样就进行源码级的调试了,
内核模块源码级调试
模块调试与kernel 有点不一样,因为模块是insmod之后才知道哪些代码段,数据段在哪里。 所以先进入模块的sections 获取代码段,数据段,再利用add-symbol-file 传递数据、代码段地址,就可以调试了。
待机调试
一个真实的故事,一个工程师调手机的待机,一个电路板上有很多个硬件,这个硬件的驱动里面都有一个suspend,之前suspend的时候系统会hang住,这个工程师之前花了一个星期在所有的suspend函数加上printk打印调试,其实这样如此通用的需求,很多公司很多人都有,最后其实只要在bootargs,加入no_console suspend ,以及pm相关的debug打开,这样suspend的时候,linux自动把suspend的信息打开, 从这个例子之后,我明白了一个linux常识,linux是一个如此强大生态,怎么轮到我发明一份新的需求,也不会已如此野蛮,呆板的实现方式,很多牛人早就想到了,并实现了一套牛x的方式。
OOPS & Panic
其实oops已经完整告诉了内核出错信息,出错的原因,比如下面例子是访问了一个NULL指针,出错的PC指针位置是globalfifo_read + 0x50/0x200(flobalfifo_read 最开始一条指令偏移0x50的位置,flobalfifo_read 整个代码段加起来是0x200) ,之后会列出完整的backtrace。
这时候就需要反汇编来调试,一般反汇编ko,或者对应的.o 文件就可以了,没必要反汇编整个内核,那样时间就非常久了。
工程上objdump比用addr2ine 要更全面和有助于调试
打开反汇编结果,找到出错的globalfifo_read ,再找到偏移 0x394 +0x50 =0x3e4, 不仅找到了出错的c代码,也可以精确到汇编。
Oops 与 Panic不是一回事,他们打印是差不多的,Panic 之后内核一定是挂了,oops 不会崩溃。Oops 一般是在进程上下文,所以内核通常只是把进程挂掉,中断上下文的oops 会导致panic,当然如果我们设置了panic_on_oops 为1 ,就都会panic。工程上通常会把panic_on_oops 上打开,因为不确定oops到底改了哪些东西,后面搞不好会有莫名其妙的错误,使得调试更加复杂。
grabserial
这个工具会打印两个时间戳,第一个是接收到打印的时间,第二个是与上一个打印的时间差,这样对我们优化开机时间比较有帮助。
内核的debug选项
内核中有很多的debug选项,默认大部分是不打开的一般在调试某个功能的时候把相关选项打开,比如调试电源管理,需要把no console suspend打开。Linux是一个如此强大的生态,基本上你想到的所有的需求,linux都为你准备好了,不要自己去摸索创造。
比如在spinlock 或者中断上下文调用了sleep,崩溃的位置不一定在中断或者spinlock里面。所以很难去调试,内核里面有个DEBUG_ATOMIC_SLEEP 打开,内核中spinlock中只要调用了sleep相关的函数(mutex malloc),内核就会打印出来,很多错误都可以去google 查找到相关的问题。通常我们费尽脑汁想的事情,别人早就想过了。
对于内存的践踏,或者多次free,或者free之后访问等问题。
举一个kmalloc 内存泄漏的例子。曾经有个研究所有一个内存泄漏的问题,他们的平台是芯片厂商直接提供的BSP,他们在上面跑一个qt程序,发现跑个把月之后内存就耗尽了,一直查,各种怀疑人生,怀疑自我,不断替换qt版本,去掉应用程序的等,搞了一年没有搞定,最后要交货了没办法,找了咨询机构解决。咨询的工程师只花了3天解决。
首先看是不是内存泄漏,发现Free命令确实是随着时间推移,内存在减少
接着看看所有应用程序的uss 追踪一段时间,没有变化
再看看proc/meminfo 里面的slab区域,发现随着时间的推移,slab区域在变化,再进一步查看一下proc/slabinfo ,slabinfo会显示内核每个slab object分配情况,发现里面有个很小的kmalloc区域在慢慢变大,从而确定是内核的内存泄漏
把内核的kmemleak 去监控内存的泄漏,最后发现是芯片公司给他们的BSP 有个bug,里面有个指针是kmalloc 出来,指针指向的内容也是kmalloc出来的,芯片BSP工程师范了个错误,他只释放了指针指向的内容的内存,指针没有释放,所以导致每次就泄漏几个字节
所以linux工程师 懂linux是一个基础,否则就会话大量的时间解决不了问题,最后怀疑人生。比如这个,懂内存管理的话,很容易查到问题所在。
Double free:
Kmalloc内存越界:
Kmalloc内存泄漏(注意在启动参数中使能kmemleak=on,内核congfig只配置没使能)
这个文件会把怀疑的内存泄漏点记录下来
Lockup 检测
对于softlockup ,比如某个线程调用了spinlock,这时候cpu抢占就关闭了,linux会调用一个高优先级的实时线程,线程里面有个计数器每次加一,并且有个定时器判断计数器是否有没有加1 ,计数器来了之后中断中检测计数器一直没更新,就证明系统已经softlockup了,此时系统会打印出来,定位到backtrace。
对于hardlockup,比如某个cpu上连中断都锁住了,中断都无法进入。Linux里面必须使用NMI 非可屏蔽的中断,(内核编译的时候使能)。
所以调试的时候发现内核没有响应了,这时候就可以打开lockup调试
再多的工具和手段也代替不了解决问题的思维,只有不断的去实践,才能找到解决问题的“感觉”
还没有评论,来说两句吧...