Lenky个人站点

也许，我们还记得各大Linux发型版提供的debuginfo安装包，比如fedora：http://fedoraproject.org/wiki/Packaging:Debuginfo，这种将可执行程序与调试符号分离的方案好处多多。一方面，缩减了可执行程序的文件大小，在一定程度上提高了程序的执行性能，另一方面，对应的调试符号文件也方便了一些不时之需。本文就来看一下与此相关的两个问题。

在Linux系统里，假设有两处代码（比如不同线程的两个函数F1和F2）都要获取两个锁（分别为L1和L2），如果F1持有L1后再去获取L2，而此时恰好由F2持有L2且它也正在尝试获取L1，那么此时就是处于死锁的状态，这是一个最简单的死锁例子，也即所谓的AB-BA死锁。

举个例子，有示例代码如下：

不得不说printk()函数是一个伟大的调试工具，它几乎能帮助我们在Linux系统的任何位置把我们想要的数据打印出来，但同时这也是一个比较耗时的过程，因为我们得把printk()函数加入到Linux内核源码的对应位置，重新编译模块，如果是内核修改，那么也许还得重启机器。

已有各种工具可以帮助我们调试内核，比如UML、kgdb、qemu等，但比较麻烦的是gdb经常给我一个“value optimized out”的提示，而且执行的路径与gdb的显示也不对应，最近我在利用UML调试ext3文件系统的逻辑时就为此而感到非常麻烦（2.6.30.8的内核）：

最近在公司看Linux内核的nmi死锁检测功能的实现机制，当然，是因为它变了，所以我才看的，简单来说就是在红帽的某牛提交了一个内核patch：new nmi_watchdog using perf events，这个patch已经被合入到内核主线2.6.38版本，所以使用自该版本开始后内核的Linux系统，其/proc/interrupts显示的中断数不再按每秒1000次的频率增长。关于new nmi_watchdog问题，本文不再多说，后续写专篇文章，下面看使用systemtap调试Linux内核的几个案例，因为我最近就是通过这个手段来理解new nmi_watchdog的实现机制，相比利用printk或kgdb而言，使用systemtap更为简单方便，效率也大大提高。

elf是Linux系统下最通用的可执行程序的文件格式，关于elf文件的加载与动态链接已很多的相关资料，而本文尝试着重介绍一下其中的一个点，即辅助向量（Auxiliary Vector）。
当一个elf文件被加载并作为一个进程开始执行之前，加载器会把相关信息传递给它，这其中除了用户设置的启动参数以外，还有系统环境的信息（即通常所说的环境变量）以及本文的主角：辅助向量。
对于用户参数和环境变量及其它们各自的作用，我们并不陌生，而且还很经常的使用，特别是用户参数，这无需多说，但对于辅助向量，却不明就里。事实上，辅助向量另外一种由内核向应用程序传递信息的方式。

何追踪函数的完整调用过程？对于软件编程人员来说，这一个有趣的话题，而在stackoverflow上就恰好有这么一个讨论，本文就对这个讨论里的内容进行一下实际操作与转述。
我们知道两个命令，ltrace和strace，其中ltrace用于追踪记录动态库函数的调用执行，而strace用于追踪记录系统调用函数的调用执行，看示例：

AMD64，由AMD公司提出来的64位技术，由于它能很好的向下兼容32位，因此在与Intel公司的纯64技术IA64（即无法向下兼容）进行竞争的过程中占据着绝对的市场优势，当然，Intel公司不会自甘落后，因此也相继推出了IA32E（后被正式命名为EM64T，Extended Memory 64 Technology），IA32E与AMD64完全兼容，所以它们也被统称为AMD64技术。相比之前的x86-32架构，AMD64被称x86-64架构，在一般情况下，单独的x86指代的x86-32，而x86-64以x64为简称。

我们知道，Linux系统分为用户态和内核态，当用户态的应用程序请求执行内核态代码获取相关内核服务时，需要通过系统调用的形式来完成，比如利用系统调用getuid()请求获取执行程序的真实用户ID号。
当然，getuid()只是glibc封装的库函数，我们也可以直接通过syscall函数（这里是指glibc库里的syscall接口，请和后面文章将提到的syscall指令区分开）进行调用：

久闻systemtap工具的大名，之前也断断续续的看过它的介绍，并且利用CentOS发行版自带的systemtap相关命令试用过几次，感觉还算不错。本文将介绍一下systemtap的安装，以及对应用程序的追踪示例，不过，在此之前，先描述一下systemtap的背景知识以及相关资料。

我们知道，在平常编译程中所使用的gcc或g++只是一套工具集的外包封装，具体的编译工作并不是由gcc本身来完成的，而gcc为了完成整个编译工作，它直接或间接调用的工具主要包括预处理器/分析编译器/汇编器/连接器（preprocessor/parser-compiler/assembler/linker），比如cpp，cc1，cc1plus，as和ld等等。
如何查看gcc在编译过程的细节？这很简单，带上-v或-###参数（两者有差别，具体请看man手册：man gcc）即可，如下：