叫好与叫座虽然不是对立面，但想在同一个作品中达到双重效果很难。

内存溢出 OOM （out of memory），是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个int,但给它存了long才能存下的数，那就是内存溢出。

【系统】Linux 启动优化

下图展示了 Linux 系统中有用的工具。

coresight-400，其实就是ARM实现coresight系统的套件，包含了coresight的各个组件，我们利用这个套件，就不再需要自己单独去设计以及验证这些coresight组件，直接拿过来，搭建soc环境。并且coresight-400组件，还提供了一些测试case，可以用来验证搭建的coresight系统，是否正确。更多的信息，查看ARM提供的coresight-400组件文档。自此，ARM的coresight介绍到此完毕，附件是整合的文档。

coresight具有两大功能，一个是debug，一个是trace。

APB和ATB总线，是coresight中常用的2个总线。对于coresight组件的访问，而，使用ATB总线进行传输。

在一个soc中，有多个coresight组件，，去获取这些coresight组件的信息了？这个时候，就需要靠coresight组件中，ARM规定，在一个soc中，必须要实现至少1个Rom table，该Rom table，rom table只会占用一个4K空间大小，也就是PIDR4寄存器的SIZE为0。

channel interface是用来使不同coresight组件之间传递event使用。使用两个组件来实现：◾CTM: cross trigger matrix， 接收CTI的channel信号，然后广播给其他CTI◾CTI：cross trigger interface， 接收trigger信号，发送trigger信号，接收channel信号，发送channel信号channel interface的典型应用。每个coresight组件和对应的CTI相连，那这个CTI就可以。

比如可以规定，该寄存器的最低位，表示最近该寄存器被读取过，第1位，表示最近该寄存器被写过。CLAIMCLR寄存器：CLAIMSET寄存器。

在gdb中运行，遇到段错误会自动停下来，这时可以用命令查看当前执行到哪一行代码了。gdb显示段错误出现在_IO_vfscanf函数中，用bt命令可以看到这个函数是被main.c的第6行间接调用的，也就是scanf这行代码引发的段错误。继续调试上一节的程序，上一节最后提出修正Bug的方法是在循环中加上判断条件，如果不是数字就报错退出，不仅输入字母可以报错退出，输入超长的字符串也会报错退出。gdb指出，段错误发生在第19行。可是这一行什么都没有啊，只有表示main函数结束的}括号。

这个暂时解释不了，但123407这个结果可以解释了，是12345×10 + 0x05-0x30得到的，虽然多循环了一次，但下次一定会退出循环了，因为0x05的后面是’\0’。已经很明显了，每次都是回到for循环开头的时候改变了input[5]的值，而且是每次加1，而循环变量i正是在每次回到循环开头之前加1，原来input[5]就是变量i的存储单元，换句话说，i的存储单元是紧跟在input数组后面的。怎么会有下一次循环呢？=‘\0’，而本来应该是0x00的位置现在莫名其妙地变成了0x04，因此循环不会结束。

至于应该在哪里设置断点，怎么知道哪些代码可以跳过而哪些代码要慢慢走，也要通过对错误现象的分析和假设来确定，以前我们用printf打印中间结果时也要分析应该在哪里插入printf，打印哪些中间结果，调试的基本思路是一样的。接下来的循环从左到右扫描字符串并把每个数字累加到结果中，例如输入"2345"，则循环累加的过程是(((0×10+2)×10+3)×10+4)×10+5=2345。可见断点有助于快速跳过没有问题的代码，然后在有问题的代码上慢慢走慢慢分析，“断点加单步”是使用调试器的基本方法。

程序中除了一目了然的Bug之外都需要一定的调试手段来分析到底错在哪。到目前为止我们的调试手段只有一种：根据程序执行时的出错现象假设错误原因，然后在代码中适当的位置插入printf，执行程序并分析打印结果，如果结果和预期的一样，基本上证明了自己假设的错误原因，就可以动手修正Bug了，如果结果和预期的不一样，就根据结果做进一步的假设和分析。

TAP声明测试访问端口（TAP）是JTAG的核心。OpenOCD必须了解您板上的活动TAP。

Reset ConfigurationEvery system configuration may require a different reset configuration. This can also be quite confusing. Resets also interact with reset-init event handlers, which do things like setting up clocks and DRAM, and JTAG clock rates. (See J

调试适配器配置正确安装OpenOCD包括使您的操作系统允许OpenOCD访问调试适配器。一旦完成，，并配置如何使用它。注意：因为OpenOCD一开始只关注JTAG，所以您可能会发现它错误地认为JTAG是唯一正在使用的传输协议。请注意，最近版本的OpenOCD正在消除这一限制。。其他传输不支持边界扫描操作，或者可能是特定于给定的芯片供应商的。有些可能只用于编程闪存，而不适用于调试。

此处的命令通常在openocd.cfg文件中找到，用于指定使用的TCP/IP端口以及应如何支持GDB。

设置目标后，您可以定义在SMP中工作的目标列表。在上面的示例中，2个CPU在SMP中工作。在SMP中，只创建了一个GDB实例，并且：一组硬件断点在列表中的所有目标上设置相同的断点。停止命令触发列表中的所有目标的停止。恢复命令触发写入上下文和列表中所有目标的重新启动。在断点之后：被断点停止的目标将显示到GDB会话中。实现专用的GDB串行协议数据包，用于切换/检索GDB会话显示的目标，请参阅将OpenOCD SMP与GDB一起使用。SMP行为可以动态禁用/启用。

您的配置应该确保此操作始终成功。通常，OpenOCD然后开始作为服务器运行。或者，可以使用命令终止配置尽早暂存，执行工作（例如更新一些闪存）， 然后在不充当服务器的情况下关闭。一旦OpenOCD开始作为服务器运行，它就会等待来自 客户端（Telnet、GDB、RPC）并处理通过 发出的命令 那些渠道。如果遇到问题，可以通过以下方式启用内部调试消息 选项。-d也可以使用命令行开关将 Jim-Tcl 命令与配置脚本交错。-c启用调试输出（在报告问题或处理 OpenOCD 时） 本身），使用命令行开关。

开放式片上调试器（OpenOCD）旨在提供调试，嵌入式目标的系统内编程和边界扫描测试设备。它是在调试适配器的帮助下完成的，该适配器是一个小型硬件模块，有助于提供正确的类型向正在调试的目标发出电信号。这些是必需，因为调试主机（运行 OpenOCD 的主机）不会通常对此类信令或连接器具有本机支持需要连接到目标。此类调试适配器支持一个或多个传输协议，每个都涉及不同的电信号（并使用在该信令之上的不同消息传递协议）。那里调试适配器的类型很多，没有统一性的名称。

对于光盘中的 u-boot，已经增加的自动识别代码，无需定义这个宏。虽然不能在 Windows 下编译 u-boot，但是只要有 elf 格式的可执行文件和源代码，还是可以在 Eclipse 下调试的。E:\eclipse_projects\u-boot 目录下的 u-boot.bin、u-boot 是 u-boot-1.1.6_OpenJTAG.tar.bz2 在Linux 下编译好的可执行文件，u-boot.bin 是二进制格式，u-boot 是 elf 格式。

使用 gdb 命令行进行调试，启动与退出文件操作查看源程序断点操作监视点操作数据操作执行程序帮助其他命令。

使用 OpenOCD、OpenJTAG 烧写程序、调试程序对于 S3C2410、S3C2440、S3C6410 开发板，大多使用 sjf2410.ext、sjf2440.exe、sjf6410等工具通过并口 JTAG 接口板烧写程序，并口 JTAG 的速率非常低，烧写 128K 的文件至少耗时 10 多分钟。后来又出现了 H-JTAG 工具，它也是使用并口 JTAG 接口板并且速度很快，但是目前只支持烧写 Nor Flash，不支持 Nand Flash。

在嵌入式开发中，有很多优秀的调试、仿真工具，比如 Keil、IAR、Rowley Associates 等。它们的安装、使用都很便利，功能强大，但是价格昂贵(几百美元甚至更多)；还要购买相应的硬件，比如 J-Link、U-Link 等 USB 到 JTAG 的转换盒，这也是一笔不小的开支。对于学生，或者是开发预算有限的工程师来说，完全可以使用免费的开发工具 Eclipse、OpenOCD，然后通过一些便宜的 JTAG 转接器(比如并口 JTAG 等)就可以达到接近、甚至超越上述商业软件的效果。并

注入到我们想要追踪的内核函数执行前后，当内核函数执行时触发我们定义的函数，我们在函数中实现获取我们想要的上下文信息并保存下来。

不过在当前内核版本中，其已经支持了更多的功能，如保存console日志、ftrace消息和用户空间日志。同时，它还支持将这些消息保存在不同的存储设备中，如内存、块设备或mtd设备【Memory Technology Devices】。为了提高灵活性和可扩展性，pstore将以上功能分别抽象为前端和后端，其中像dmesg、console等为pstore提供数据的模块称为前端，而内存设备、块设备等用于存储数据的模块称为后端，pstore core则分别为它们提供相关的注册接口。

当内核出现致命错误时，只要cpu还能正常运行，那么最重要的就是向用户输出详细的错误信息，以及保存问题出现时的错误现场。以上致命错误可包含以下两种类型：（1）硬件能检测到的错误，如非法内存访问，非法指令等，此时cpu会触发异常，并进入异常处理流程。在异常处理流程中会触发oops或panic。（2）内核代码进入某些代码无法处理的异常分支，此时程序若继续执行可能会导致无法预知的后果，此时相关的代码会主动进入oops或panic。其中panic的含义为惊恐、恐慌，即内核将无法继续进行，它会根据配置确定是否dump

linux内核包括进程管理、内存管理、中断管理、设备驱动、同步机制等各种模块，它们共同运行在一个共享的地址空间中，因此在运行中一旦出现问题，彼此之间可能具有千丝万缕的联系。而且与用户态不同，内核还需要与形形色色的硬件打交道，因此对于某些较为诡异的问题，除了软件以外还可能受到硬件的影响。如由于射线或电磁辐射的原因造成内存中某个bit翻转，或者某些非法总线地址的访问，导致总线挂死等。更进一步，内核作为系统的基础服务提供者，

比如我们进行一个系统调用，出来的时间过长，我们想知道时间花哪里去了，利用Ftrace就可以追踪到一级级的时间分布。

对于这个系列真的是千呼万唤始出来，苦于自己在内核态的定位手段极其的单一。于是来学习一些内核的定位方法。这个系列会开始不断的学习，我觉得调试手段和基础知识都很重要。磨刀不误砍柴工。

ftrace最早出现在Linux2.6.27版本中，其设计目标简单，基于静态代码插桩技术，不需要用户通过额外的编程来定义跟踪行为。（打桩这个根据字面意思就知道是打标记点，然后将标记点连接操作，形容出轨迹）静态代码插桩技术比较可靠，不会因为用户的不当使用而导致内核崩溃。ftrace的名字由functiontrace而来，它利用gcc编译器的profile特性在所有函数入口处添加了一段插桩代码，ftrace重载这段代码来实现跟踪功能。常用的ftrace跟踪器如下。nop不跟踪任何信息。......

在内核跑起来之前，有些前置知识需要了解一下，这些可以作为我们的工具，更加帮助我们以后查看内核的信息与调试。文章内容全部来自《奔跑吧Linux内核》

ftrace最早出现在Linux2.6.27版本中，其设计目标简单，基于静态代码插桩技术，不需要用户通过额外的编程来定义跟踪行为。（打桩这个根据字面意思就知道是打标记点，然后将标记点连接操作，形容出轨迹）静态代码插桩技术比较可靠，不会因为用户的不当使用而导致内核崩溃。ftrace的名字由functiontrace而来，它利用gcc编译器的profile特性在所有函数入口处添加了一段插桩代码，ftrace重载这段代码来实现跟踪功能。常用的ftrace跟踪器如下。nop不跟踪任何信息。............

很多内核开发者最喜欢的调试工具之一是printk。printk是内核提供的格式化打印函数，它和C库所提供的printf()函数类似。printk()函数和printf()函数的一个重要区别是前者提供打印等级，内核根据这个等级来判断是否在终端或者串口中打印输出。但是其实就是我们平时调试一些逻辑的时候，我想知道这个代码到这一步的状态和功能，那就在这里整个printf。这个是异曲同工之妙那为什么有了prink还需要整这些呢，这是因为你打印吧，你得在内核编译运行之前固定，这就不动态。......

Linux内核树编译错误整理编译Linux内核kernel时遇到的问题与解决方案问题1：scripts/sign-file.c:25:10: fatal error: openss1/opensslv.h: No such file or directory解决方法：sudo apt-get install libssl-dev1问题2：/bin/sh: 1: flex: not found解决方法sudo apt-get install flex1问题3：/bin/sh: 1: bis