欢迎来到开发者手册。本手册还在不断完善中，是许多人共同努力的成果。许多部分尚不存在，一些已存在的部分也需要更新。如果您有兴趣参与这个项目，请发送电子邮件至 FreeBSD 文档项目邮件列表。

本文档的最新版本始终可从 FreeBSD 全球网络服务器获取。也可以从 FreeBSD 下载服务器或众多镜像站点之一以各种格式和压缩选项下载。

版权 © 1995-2023 FreeBSD 文档计划

适用于希望为 FreeBSD 开发软件的人（而不仅仅是开发 FreeBSD 本身的人）

2.1. 概要

本章是关于如何使用 FreeBSD 附带的一些编程工具的介绍，尽管其中大部分内容同样适用于许多其他版本的 UNIX®。本章不会尝试详细描述编码过程。大多数内容假设读者几乎没有或根本没有编程经验，尽管希望大多数程序员仍能从中找到一些有价值的内容。

2.2. 引言

然而，如果你从未在 UNIX® 平台上编写过程序，这些强大工具在最初可能会令人感到困惑。本文档的目标是帮助你快速上手，而不深入涉及高级主题。我们希望本文档能为你提供足够的基础知识，使你能够理解相关文档的内容。

大多数内容几乎不需要任何编程知识，尽管它假设你对 UNIX® 的基本操作已有一定掌握，并且愿意学习！

2.3. 编程简介

程序是一组指令，告诉计算机执行各种操作；有时它要执行的指令还取决于之前执行某条指令时发生了什么。本节将概述你可以给出这些指令（通常称为“命令”）的两种主要方式：一种是使用 解释器，另一种是使用 编译器。由于人类语言对于计算机来说太复杂，难以实现明确理解，因此这些命令通常以专门为此设计的语言编写。

2.3.1. 解释器

使用解释器时，语言本身是作为一个环境存在的，你可以在提示符下输入命令，解释器会立即执行这些命令。对于更复杂的程序，你可以把命令写进一个文件，然后让解释器加载并执行这个文件中的命令。如果出错，许多解释器会将你带入调试器，以帮助你查找问题。

这种方式的优点在于你可以立即看到命令的执行结果，错误也可以快速修正。最大的缺点是在你想与他人分享程序时，对方必须拥有相同的解释器，或者你必须以某种方式提供给他们这个解释器，并且他们还需要知道如何使用它。此外，用户在按错键后直接进入调试器的情况，可能也会让人不太舒服。从性能角度来看，解释器通常消耗较多内存，生成的代码效率也不如编译器高。

我认为，如果你从未编程过，解释型语言是最好的入门方式。这类环境典型地见于 Lisp、Smalltalk、Perl 和 Basic 等语言。也有人认为 UNIX® 的 shell（如 sh、csh）本身就是一种解释器，事实上很多人确实会编写 shell “脚本”来辅助完成他们机器上的各种“维护”任务。实际上，UNIX® 最初的理念之一就是提供许多可以在 shell 脚本中组合使用的小型实用程序，以完成有用的任务。

2.3.2. FreeBSD 提供的解释器

下面是一些可以通过 FreeBSD Ports 获取的解释器列表，并简要介绍了一些较为流行的解释型语言。

BASIC BASIC 是 “Beginner’s All-purpose Symbolic Instruction Code”（初学者通用符号指令代码） 的缩写。它在 20 世纪 50 年代被开发出来，用于教授大学生编程；而在 20 世纪 80 年代，每台自重的个人计算机都配备了 BASIC，使它成为许多程序员的第一门编程语言。它也是 Visual Basic 的基础。

Lisp Lisp 是在 20 世纪 50 年代末期开发的一种语言，用于替代当时流行的“数值计算”语言。它不是基于数字，而是基于列表；事实上，其名称就是 “List Processing”（列表处理） 的缩写。它在人工智能（AI）领域中非常流行。

Lisp 是一种极其强大而复杂的语言，但可能显得庞大且不易掌握。

Perl Perl 在系统管理员中非常流行，用于编写脚本；它也常用于 Web 服务器上编写 CGI 脚本。

Scheme Scheme 是 Lisp 的方言，它比 Common Lisp 更紧凑、更清晰。在大学中很受欢迎，因为它足够简单，可以作为初学者的第一门语言教学，同时抽象程度也高，适合用于科研工作。

Python Python 是一种面向对象的解释型语言。它的支持者认为这是一门非常适合初学者的语言，因为它容易上手，但并不像其他用于开发大型复杂应用的解释型语言那样受到限制（Perl 和 Tcl 是另外两种常用于此类开发的语言）。

Ruby Ruby 是一种解释型的纯面向对象编程语言。它因其易于理解的语法、编写灵活性强以及便于开发与维护大型复杂程序而广受欢迎。

Tcl 和 Tk Tcl 是一种可嵌入的解释型语言，因其良好的跨平台特性而得到广泛应用和普及。它既可用于快速编写小型原型应用，也可与 Tk（一个图形用户界面工具包）结合开发功能完备的正式程序。

2.3.3. 编译器

显然，这种方式不像使用解释器那样直接。然而，它允许你做很多用解释器很难甚至不可能完成的事情，比如编写与操作系统密切交互的代码——甚至编写你自己的操作系统！如果你需要编写高效的代码，它也非常有用，因为编译器可以花时间优化代码，而解释器则无法接受这种优化。此外，为编译器编写的程序通常比为解释器编写的程序更易于分发——你只需要给他们一个可执行文件副本，前提是他们使用的操作系统与你相同。

2.4. 使用 cc 编译

一旦你编写完你的杰作，下一步就是将它转换成能够（希望！）在 FreeBSD 上运行的形式。这通常涉及几个步骤，每个步骤都由一个独立的程序完成。

1. 预处理你的源代码，移除注释并进行其他操作，如在 C 中展开宏。

2. 检查你的代码的语法，查看你是否遵循了语言的规则。如果没有，它会报错！

3. 将源代码转换为汇编语言——这非常接近机器代码，但仍然可以被人理解。据说。

4. 将汇编语言转换为机器代码——是的，我们在谈论的是比特和字节，1 和 0。

5. 检查你是否以一致的方式使用了诸如函数和全局变量之类的东西。例如，如果你调用了一个不存在的函数，它会报错。

6. 如果你试图从多个源代码文件生成可执行文件，计算如何将它们组合在一起。

7. 计算如何生成一个系统的运行时加载器能够加载到内存并运行的程序。

8. 最后，将可执行文件写入文件系统。

“编译”一词通常仅指步骤 1 到 4，其余步骤被称为 链接。有时步骤 1 被称为 预处理，步骤 3-4 被称为 汇编。

幸运的是，几乎所有的细节都被隐藏了，因为 cc 是一个前端，它为你管理调用所有这些程序并传递正确的参数；只需输入

% cc foobar.c

就会将 foobar.c 按照上述步骤进行编译。如果你有多个文件需要编译，只需像这样操作：

% cc foo.c bar.c

cc 有很多选项，都可以在手册页中找到。以下是一些最重要的选项，并附有如何使用它们的示例。

% cc foobar.c               可执行文件是 a.out
% cc -o foobar foobar.c     可执行文件是 foobar

-c 仅编译文件，不进行链接。对于只想检查语法的简单程序，或使用 Makefile 的情况非常有用。

% cc -c foobar.c

这将生成一个名为 foobar.o 的 目标文件（而不是可执行文件）。可以将该目标文件与其他目标文件一起链接，生成可执行文件。

-g 生成可调试版本的可执行文件。这会使编译器将有关源文件和函数调用行的信息添加到可执行文件中。调试器可以利用这些信息，在你单步调试程序时显示源代码，这 非常 有用；缺点是这些额外的信息会使程序变得更大。通常，在开发程序时使用 -g 编译，而在确认程序正常工作后，则不使用 -g 编译“发布版本”。

% cc -g foobar.c

-O 生成优化版本的可执行文件。编译器执行各种巧妙的操作，尽力生成比普通版本运行更快的可执行文件。你可以在 -O 后添加一个数字，以指定更高等级的优化，但这往往会暴露编译器优化器中的 bug。

% cc -O -o foobar foobar.c

这将生成优化版的 foobar。

以下三个标志会强制 cc 检查你的代码是否符合相关的国际标准，通常称为 ANSI 标准，严格来说是 ISO 标准。

-Wall 启用 cc 作者认为值得启用的所有警告。尽管名称为 “Wall”，但它并不会启用 cc 能够生成的所有警告。

-ansi 关闭 cc 提供的大多数非 ANSI C 特性。尽管名称为 “ansi”，但它并不能严格保证你的代码符合标准。

-pedantic 关闭 cc 的 所有 非 ANSI C 特性。

没有这些标志，cc 将允许你使用一些其非标准的扩展功能。这些扩展虽然非常有用，但可能无法与其他编译器兼容——事实上，标准的主要目的之一就是允许人们编写能够在任何编译器和系统上运行的代码。这被称为 可移植代码。

通常，你应该尽量使代码具有可移植性，否则你可能需要在以后完全重写程序，以便它能够在其他地方工作——谁知道你几年后会使用什么呢？

% cc -Wall -ansi -pedantic -o foobar foobar.c

这将在检查 foobar.c 是否符合标准后生成一个名为 foobar 的可执行文件。

-l <library> 指定在链接时使用的函数库。

最常见的例子是在编译一个使用 C 中一些数学函数的程序时。与大多数其他平台不同，这些数学函数被放在一个与标准 C 库分开的库中，你需要告诉编译器将其添加进去。

规则是，如果库的名称是 libsomething.a，你需要给 cc 传递 -l<something> 参数。例如，数学库是 libm.a，因此你需要传递 -lm 给 cc。关于数学库的一个常见“陷阱”是，它必须是命令行中最后一个库。

% cc -o foobar foobar.c -lm

这将把数学库的函数链接到 foobar 中。

如果你正在编译 C++ 代码，使用 c++。在 FreeBSD 上，c++ 也可以通过 clang++ 调用。

% c++ -o foobar foobar.cc

这将从 C++ 源文件 foobar.cc 生成一个可执行文件 foobar。

2.4.1. 常见的 cc 查询和问题

2.4.1.1. 我编译了一个名为 foobar.c 的文件，但找不到名为 foobar 的可执行文件。它去了哪里？

记住，除非你特别告诉它，否则 cc 会将可执行文件命名为 a.out。使用 -o <filename> 选项：

% cc -o foobar foobar.c

2.4.1.2. 好的，我有一个名为 foobar 的可执行文件，在运行 ls 时能看到它，但当我在命令行中输入 foobar 时，告诉我没有这样的文件。为什么它找不到？

与 MS-DOS® 不同，UNIX® 在查找你要运行的可执行文件时，不会自动在当前目录中查找，除非你告诉它。输入 ./foobar，意思是“运行当前目录下名为 foobar 的文件”。

2.4.2. 我叫我的可执行文件为 test，但运行时什么也没发生。怎么回事？

大多数 UNIX® 系统都有一个名为 test 的程序，它位于 /usr/bin 目录，Shell 在检查当前目录之前会先找到它。你可以输入：

% ./test

或者给你的程序取个更好的名字！

2.4.2.1. 我编译了程序，刚开始似乎运行得很好，然后出现了一个错误，说什么“core dumped”。那是什么意思？

core dump 这个名字来源于 UNIX® 初期，当时计算机使用核心内存来存储数据。基本上，如果程序在某些条件下失败，系统会将核心内存的内容写入一个名为 core 的文件，程序员可以查看该文件以找出问题所在。

2.4.2.2. 很有意思，但我现在该做什么？

2.4.2.3. 当我的程序发生 core dump 时，它提到一个“segmentation fault”。那是什么意思？

这基本上意味着你的程序尝试对内存执行某种非法操作；UNIX® 设计的目的是保护操作系统和其他程序免受恶意程序的影响。

常见的原因包括：

• 尝试写入 NULL 指针，例如：

  复制

  char *foo = NULL;
  strcpy(foo, "bang!");

• 使用未初始化的指针，例如：

  复制

  char *foo;
  strcpy(foo, "bang!");

  指针将具有一些随机值，运气好的话，它会指向一个程序无法访问的内存区域，内核会在程序产生任何损害之前终止它。如果运气不好，它可能会指向你程序内部的某个地方，破坏你的数据结构，导致程序神秘地失败。

• 尝试访问数组末尾之外的元素，例如：

  复制

  int bar[20];
  bar[27] = 6;

• 尝试存储到只读内存中，例如：

  复制

  char *foo = "My string";
  strcpy(foo, "bang!");

  UNIX® 编译器通常会将类似 "My string" 的字符串字面量放入只读内存区域。

• 对 malloc() 和 free() 做不当操作，例如：

  复制

  char bar[80];
  free(bar);

  或者

  复制

  char *foo = malloc(27);
  free(foo);
  free(foo);

做出这些错误并不总是会导致程序出错，但它们总是糟糕的实践。某些系统和编译器对这些错误的容忍度不同，这就是为什么在一个系统上运行良好的程序，在另一个系统上可能会崩溃的原因。

2.4.2.4. 有时当我得到一个 core dump 时，它说是 bus error。我在 UNIX® 书上看到说这意味着硬件问题，但电脑似乎还在工作。这是真的吗？

不，幸运的是不是（当然，除非你真的遇到了硬件问题…）。这通常是指你以不应有的方式访问了内存。

2.4.2.5. 这个 core dump 的过程看起来很有用，如果我能在需要时使其发生就好了。我可以这样做吗，还是只能等到出错？

是的，你可以这样做，只需去另一个控制台或 xterm，执行

% ps

找出你的程序的进程 ID，然后执行

% kill -ABRT pid

其中 <pid> 是你查找的进程 ID。

如果你的程序陷入了死循环，这会很有用。如果程序捕获了 SIGABRT 信号，还有其他一些信号也有类似的效果。

2.5. Make

2.5.1. 什么是 make？

当你在处理一个简单的程序，只有一两个源文件时，输入

% cc file1.c file2.c

还算可以，但当有多个文件时，输入命令会变得非常繁琐——而且编译可能也会花费很长时间。

解决这个问题的一种方法是使用目标文件，并且只有在源代码发生变化时才重新编译源文件。所以我们可能会像这样：

% cc file1.o file2.o … file37.c …

如果我们只修改了 file37.c，而其他文件没有变化，则可以这样做。这样可以加快编译速度，但依然不能解决输入命令的问题。

或者我们可以写一个 shell 脚本来解决输入命令的问题，但它会重新编译所有文件，这在大型项目中非常低效。

如果我们有数百个源文件散布在不同地方呢？如果我们在一个团队中工作，而其他人没有告诉我们他们修改了我们使用的某个源文件怎么办？

也许我们可以将这两种方法结合起来，写一个 shell 脚本，其中包含某种规则，指示何时需要编译源文件。现在，我们需要一个可以理解这些规则的程序，因为这些规则对于 shell 来说有些复杂。

这个程序就是 make。它读取一个名为 makefile 的文件，文件中指定了不同文件之间的依赖关系，并根据这些规则计算哪些文件需要重新编译，哪些不需要。例如，某个规则可能会说：“如果 fromboz.o 比 fromboz.c 旧，说明 fromboz.c 可能被修改过，所以需要重新编译。”makefile 还会包含告诉 make 如何重新编译源文件的规则，这使它成为一个非常强大的工具。

makefile 通常保存在与其适用的源文件相同的目录中，并且可以命名为 makefile、Makefile 或 MAKEFILE。大多数程序员使用 Makefile 这个名字，因为它在目录列表的顶部，更容易被发现。

2.5.2. 使用 make 的示例

这是一个非常简单的 makefile：

foo: foo.c
	cc -o foo foo.c

它由两行组成，一行是依赖关系行，另一行是创建行。

依赖关系行由程序的名称（即 目标）组成，后面跟着一个冒号，空格，再跟上源文件的名称。当 make 读取这一行时，它会查看 foo 是否存在；如果存在，它会比较 foo 的最后修改时间和 foo.c 的最后修改时间。如果 foo 不存在，或者比 foo.c 旧，它就会查看创建行，了解该做什么。换句话说，这就是判断 foo.c 是否需要重新编译的规则。

创建行以一个制表符开始（按下 tab 键），然后是你在命令行中输入的命令，来创建 foo。如果 foo 已过期，或者不存在，make 就会执行这个命令来创建它。换句话说，这就是告诉 make 如何重新编译 foo.c 的规则。

因此，当你输入 make 时，make 会确保 foo 与你对 foo.c 的最新更改保持同步。这个原理可以扩展到有数百个目标的 Makefile——实际上，在 FreeBSD 上，你只需在合适的目录中输入 make world 就可以编译整个操作系统！

makefile 的另一个有用特点是，目标不一定非得是程序。例如，我们可以有一个像这样的 makefile：

foo: foo.c
	cc -o foo foo.c

install:
	cp foo /home/me

我们可以通过输入以下命令告诉 make 我们想要创建哪个目标：

% make target

make 会只查看该目标并忽略其他目标。例如，如果我们输入 make foo，make 会忽略 install 目标。

如果我们只输入 make，make 将始终查看第一个目标，并在查看完该目标后停止，而不会查看其他目标。所以如果我们输入 make，它会先处理 foo 目标，必要时重新编译 foo，然后停止，而不会继续处理 install 目标。

请注意，install 目标实际上并不依赖任何东西！这意味着，当我们输入 make install 来制作该目标时，接下来的命令始终会执行。在这种情况下，它会将 foo 复制到用户的家目录。这通常在应用程序的 makefile 中使用，以便在程序正确编译后，将应用程序安装到正确的目录中。

这个话题有些难以解释。如果你不完全理解 make 是如何工作的，最好的方法是编写一个简单的程序，如 hello world，以及像上面那样的 makefile，并进行实验。然后，逐步尝试使用多个源文件，或者让源文件包含一个头文件。touch 命令在这里非常有用——它可以更改文件的日期，而不需要编辑它。

2.5.3. make 和包含文件

C 代码通常以一系列要包含的文件开始，例如 stdio.h。其中一些是系统包含文件，有些则是当前项目中的文件：

#include <stdio.h>
#include "foo.h"

int main(....

为了确保一旦 foo.h 被修改，这个文件会立刻重新编译，你需要在 Makefile 中添加它：

foo: foo.c foo.h

当你的项目变大，有越来越多的自定义包含文件时，跟踪所有包含文件及其依赖的文件将变得非常麻烦。如果你修改了一个包含文件，却忘记重新编译所有依赖于它的文件，结果可能会非常糟糕。clang 提供了一个选项来分析你的文件并生成包含文件及其依赖关系的列表：-MM。

如果你在 Makefile 中添加以下内容：

depend:
	cc -E -MM *.c > .depend

并运行 make depend，那么会生成一个 .depend 文件，内容包含对象文件、C 文件和包含文件的依赖关系：

foo.o: foo.c foo.h

如果你修改了 foo.h，下次运行 make 时，所有依赖于 foo.h 的文件都会重新编译。

每次添加包含文件时，别忘了运行 make depend。

2.5.4. FreeBSD Makefile

编写 Makefile 可能相当复杂。幸运的是，基于 BSD 的系统，如 FreeBSD，提供了一些非常强大的 Makefile，这些文件是系统的一部分。一个很好的例子就是 FreeBSD 的 ports 系统。以下是一个典型的 ports Makefile 的核心部分：

MASTER_SITES=   ftp://freefall.cdrom.com/pub/FreeBSD/LOCAL_PORTS/
DISTFILES=      scheme-microcode+dist-7.3-freebsd.tgz

.include <bsd.port.mk>

现在，如果我们进入该端口的目录并输入 make，会发生以下几件事：

1. 系统检查此端口的源代码是否已经存在。

2. 如果不存在，将建立与 MASTER_SITES 中指定的 URL 的 FTP 连接来下载源代码。

3. 系统计算源代码的校验和，并与已知的源代码校验和进行比较，确保源代码在传输过程中没有损坏。

4. 应用所需的任何更改，使源代码能够在 FreeBSD 上正常工作——这称为 patching。

5. 进行源代码所需的特殊配置。（许多 UNIX® 程序在编译时会试图找出它们运行的 UNIX® 版本和所支持的 UNIX® 特性——在 FreeBSD 的 ports 系统中，这些信息会被提供给源代码。）

6. 编译程序的源代码。实际上，我们进入源代码解压的目录并执行 make——程序自己的 makefile 已包含构建程序所需的信息。

7. 我们现在得到了编译好的程序。如果需要，可以进行测试；当我们确认程序正常工作时，可以输入 make install，这会将程序和任何需要的支持文件复制到正确的位置，并在 package database 中创建条目，以便以后如果改变主意，可以轻松卸载该端口。

现在你应该会同意，这个四行的脚本非常强大！

其中的秘密就在于最后一行，它告诉 make 查找系统的 makefile 文件 bsd.port.mk。这一行很容易被忽视，但正是它包含了所有的巧妙内容——有人编写了一个 makefile，告诉 make 执行上述所有操作（包括一些我没有提到的内容，如处理可能发生的错误），任何人只需要在自己的 makefile 中加上这一行，就可以使用这些功能！

如果你想查看这些系统的 makefile，它们位于 /usr/share/mk，但最好等你熟悉了 makefile 的使用后再去查看，因为它们非常复杂（如果查看时，记得准备好一瓶浓咖啡！）

2.5.5. make 的高级用法

许多 ports 应用程序使用 GNU make，它提供了非常好的 "info" 页面。如果你已经安装了这些 ports，GNU make 会自动安装为 gmake。它也可以作为一个独立的端口或包安装。

要查看 GNU make 的 info 页面，你需要编辑 /usr/local/info 目录下的 dir 文件，添加一行：

* Make: (make).                 The GNU Make utility.

添加后，你可以输入 info 并从菜单中选择 make（或者在 Emacs 中，使用 C-h i）。

2.6. 调试

2.6.1. 可用调试器简介

使用调试器可以在更受控的环境下运行程序。通常，您可以逐行执行程序，检查变量的值，修改变量，指示调试器运行到某个特定位置后停止，等等。还可以附加到一个正在运行的程序，或加载核心文件以调查程序崩溃的原因。

注意

这两个调试器具有相似的功能集，因此选择使用哪个调试器很大程度上取决于个人喜好。如果只熟悉其中一个，可以使用该调试器。如果对两者都不熟悉，或者都熟悉但希望在 Emacs 中使用其中一个，应该选择 gdb，因为 lldb 不支持 Emacs。否则，尝试两者并看看哪个更适合自己。

2.6.2. 使用 lldb

2.6.2.1. 启动 lldb

通过输入以下命令启动 lldb：

% lldb -- progname

2.6.2.2. 使用 lldb 运行程序

使用 -g 编译程序，以便充分利用 lldb。即使不加 -g 也可以使用，但它将只显示当前正在运行的函数的名称，而不是源代码。如果它显示类似以下的行：

Breakpoint 1: where = temp`main, address = …

（没有源代码文件名和行号的指示）表示程序没有使用 -g 编译。

注意

大多数 lldb 命令都有可以替代的简短形式，这里使用了较长的形式以便更清晰。

在 lldb 提示符下，输入 breakpoint set -n main。这将告诉调试器不要显示程序运行中的初始设置代码，并在程序的代码开始时停止执行。然后输入 process launch 以实际启动程序——它将从初始设置代码开始，然后在调用 main() 时被调试器停止。

要逐行执行程序，输入 thread step-over。当程序进入函数调用时，输入 thread step-in 进入函数。一旦进入函数调用，输入 thread step-out 退出函数，或使用 up 和 down 快速查看调用者。

以下是如何使用 lldb 查找程序错误的一个简单示例。我们有一个故意出错的程序：

#include <stdio.h>

int bazz(int anint);

main() {
	int i;

	printf("This is my program\n");
	bazz(i);
	return 0;
}

int bazz(int anint) {
	printf("You gave me %d\n", anint);
	return anint;
}

此程序将 i 设置为 5 并将其传递给函数 bazz()，然后打印出我们给它的数字。

编译并运行该程序将显示：

% cc -g -o temp temp.c
% ./temp
This is my program
anint = -5360

这不是预期的结果！该是时候看看发生了什么了！

% lldb -- temp
(lldb) target create "temp"
Current executable set to 'temp' (x86_64).
(lldb) breakpoint set -n main				跳过设置代码
Breakpoint 1: where = temp`main + 15 at temp.c:8:2, address = 0x00000000002012ef	lldb 设置断点在 main()
(lldb) process launch					运行到 main()
Process 9992 launching
Process 9992 launched: '/home/pauamma/tmp/temp' (x86_64)	程序开始运行

Process 9992 stopped
* thread #1, name = 'temp', stop reason = breakpoint 1.1	lldb 停在 main()
    frame #0: 0x00000000002012ef temp`main at temp.c:8:2
   5	main() {
   6		int i;
   7
-> 8		printf("This is my program\n");			指示停在的行
   9		bazz(i);
   10		return 0;
   11	}
(lldb) thread step-over			执行到下一行
This is my program						程序打印输出
Process 9992 stopped
* thread #1, name = 'temp', stop reason = step over
    frame #0: 0x0000000000201300 temp`main at temp.c:9:7
   6		int i;
   7
   8		printf("This is my program\n");
-> 9		bazz(i);
   10		return 0;
   11	}
   12
(lldb) thread step-in			进入 bazz()
Process 9992 stopped
* thread #1, name = 'temp', stop reason = step in
    frame #0: 0x000000000020132b temp`bazz(anint=-5360) at temp.c:14:29	lldb 显示堆栈帧
   11	}
   12
   13	int bazz(int anint) {
-> 14		printf("You gave me %d\n", anint);
   15		return anint;
   16	}
(lldb)

等一下！anint 怎么变成了 -5360？它不是在 main() 中被设置为 5 吗？让我们回到 main() 看看。

(lldb) up		返回到调用栈
frame #1: 0x000000000020130b temp`main at temp.c:9:2		lldb 显示堆栈帧
   6		int i;
   7
   8		printf("This is my program\n");
-> 9		bazz(i);
   10		return 0;
   11	}
   12
(lldb) frame variable i			显示 i 的值
(int) i = -5360							lldb 显示 -5360

哦，糟糕！看看代码，我们忘记初始化 i 了。我们本应写成：

...
main() {
	int i;

	i = 5;
	printf("This is my program\n");
...

但我们忘记了 i=5; 这一行。由于没有初始化 i，它就有了程序运行时该内存位置上的任意值，在这种情况下是 -5360。

技巧

每次我们进入或退出一个函数时，lldb 命令都会显示堆栈帧，即使我们使用 up 和 down 移动调用栈时也是如此。这会显示函数的名称和其参数的值，帮助我们跟踪程序的运行情况。（调用栈是程序存储传递给函数的参数和返回时要跳转的位置的存储区域。）

2.6.2.3. 使用 lldb 检查核心文件

核心文件基本上是包含程序崩溃时完整状态的文件。在“好老的日子里”，程序员需要打印出核心文件的十六进制清单，并为机器代码手册而苦苦挣扎，但现在生活变得容易多了。顺便提一下，在 FreeBSD 和其他 4.4BSD 系统中，核心文件被称为 progname.core，而不是仅仅叫 core，以便更清楚地表明核心文件属于哪个程序。

要检查核心文件，需要在指定程序的同时指定核心文件的名称。不要像通常那样启动 lldb，而是输入 lldb -c <progname>.core -- <progname>。

调试器将显示如下内容：

% lldb -c progname.core -- progname
(lldb) target create "progname" --core "progname.core"
Core file '/home/pauamma/tmp/progname.core' (x86_64) was loaded.
(lldb)

在这个例子中，程序被命名为 progname，因此核心文件名为 progname.core。调试器不会显示程序崩溃的原因或位置。为此，可以使用 thread backtrace all。这也会显示导致程序崩溃的函数是如何被调用的。

(lldb) thread backtrace all
​ thread #1, name = 'progname', stop reason = signal SIGSEGV
   frame #0: 0x0000000000201347 progname`bazz(anint=5) at temp2.c:17:10
    frame #1: 0x0000000000201312 progname`main at temp2.c:10:2
    frame #2: 0x000000000020110f progname`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7
(lldb)

SIGSEGV 表示程序试图访问其不属于自己的内存（通常是运行代码或读写数据），但没有给出具体细节。为此，可以查看 temp2.c 文件中第 10 行的源代码，查看 bazz() 中的代码。回溯还表明，在此情况下，bazz() 是从 main() 中调用的。

2.6.2.4. 使用 lldb 附加到正在运行的程序

lldb 的一大亮点功能是它可以附加到一个已经在运行的程序上。当然，这要求有足够的权限才能执行此操作。一个常见问题是当程序进行 fork 操作并希望跟踪子进程时，调试器通常只会跟踪父进程。

为此，启动另一个 lldb，使用 ps 查找子进程的进程 ID，然后在 lldb 中执行

(lldb) process attach -p pid

然后像往常一样进行调试。

为了让这个过程顺利工作，调用 fork 创建子进程的代码需要做如下处理（摘自 gdb 的信息页面）：

...
if ((pid = fork()) < 0)		/* _始终_ 检查这个 */
	error();
else if (pid == 0) {		/* 子进程 */
	int PauseMode = 1;

	while (PauseMode)
		sleep(10);	/* 等待直到有人附加到我们 */
	...
} else {			/* 父进程 */
	...

现在，只需要附加到子进程，在 lldb 中执行 expr PauseMode = 0，并等待 sleep() 调用返回。

2.6.3. 使用 LLDB 进行远程调试

注意

从 LLDB 12.0.0 开始，FreeBSD 支持远程调试。这意味着可以在一台主机上启动 lldb-server 来调试程序，而交互式的 lldb 客户端则可以从另一台主机连接到它。

要启动一个需要远程调试的程序，请在远程服务器上运行 lldb-server，命令如下：

% lldb-server g host:port -- progname

程序启动后会立即停止，lldb-server 会等待客户端的连接。

然后，在本地启动 lldb，并输入以下命令来连接到远程服务器：

(lldb) gdb-remote host:port

lldb-server 也可以附加到一个正在运行的进程。要做到这一点，在远程服务器上输入以下命令：

% lldb-server g host:port --attach pid-or-name

2.6.4. 使用 gdb

2.6.4.1. 启动 gdb

通过输入以下命令启动 gdb：

% gdb progname

不过许多人更喜欢在 Emacs 中运行它。要在 Emacs 中运行，输入：

M-x gdb RET progname RET

2.6.4.2. 使用 gdb 运行程序

使用 -g 选项编译程序，以便最大限度地发挥 gdb 的功能。即使不加 -g 选项，gdb 也能工作，但它只会显示当前运行的函数名称，而不是源代码。如果在启动 gdb 时看到类似以下内容：

... (no debugging symbols found) ...

这意味着程序没有使用 -g 编译。

在 gdb 提示符下，输入 break main。这将告诉调试器跳过程序中的初步设置代码，并在程序代码开始时停止执行。接着输入 run 启动程序，程序会从设置代码开始执行，并在调用 main() 时被调试器停止。

要逐行调试程序，可以按 n。当遇到函数调用时，按 s 步入该函数。进入函数后，按 f 返回，或者使用 up 和 down 快速查看调用者。

以下是使用 gdb 找到程序错误的一个简单示例。我们有如下程序（包含一个故意的错误）：

#include <stdio.h>

int bazz(int anint);

main() {
	int i;

	printf("This is my program\n");
	bazz(i);
	return 0;
}

int bazz(int anint) {
	printf("You gave me %d\n", anint);
	return anint;
}

该程序将 i 设置为 5，并将其传递给函数 bazz()，该函数打印出我们给它的数字。

编译并运行该程序，输出为：

% cc -g -o temp temp.c
% ./temp
This is my program
anint = 4231

这不是我们期望的结果！是时候看看发生了什么！

% gdb temp
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) break main				跳过设置代码
Breakpoint 1 at 0x160f: file temp.c, line 9.	gdb 在 main() 设置断点
(gdb) run					运行到 main()
Starting program: /home/james/tmp/temp		程序开始运行

Breakpoint 1, main () at temp.c:9		gdb 在 main() 停止
(gdb) n						执行下一行
This is my program				程序输出
(gdb) s						步入 bazz()
bazz (anint=4231) at temp.c:17			gdb 显示堆栈帧
(gdb)

等一下！anint 怎么成了 4231？它不是在 main() 中被设置为 5 吗？让我们回到 main()，看看。

(gdb) up					回到调用栈
#1  0x1625 in main () at temp.c:11		gdb 显示堆栈帧
(gdb) p i					显示 i 的值
$1 = 4231					gdb 显示 i 的值是 4231

哦，天哪！查看代码，我们忘记初始化 i 了。我们本来应该写：

...
main() {
	int i;

	i = 5;
	printf("This is my program\n");
...

但我们忘了写 i=5; 这一行。由于没有初始化 i，它包含了程序运行时该内存区域的任意值，而在这个情况下，恰好是 4231。

注意

每次进入或退出一个函数时，gdb 命令都会显示堆栈帧，即使我们使用 up 和 down 来在调用栈中移动。这显示了函数的名称和其参数的值，这有助于我们跟踪当前的位置和发生了什么。（堆栈是程序存储有关传递给函数的参数以及返回时应该去哪里的信息的区域。）

2.6.4.3. 使用 gdb 检查 Core 文件

Core 文件基本上是一个包含程序崩溃时完整状态的文件。在“好久以前”，程序员们不得不打印出 core 文件的十六进制清单，并靠着机器代码手册来调试，但现在生活变得轻松一些。顺便提一下，在 FreeBSD 和其他 4.4BSD 系统中，core 文件被称为 progname.core，而不仅仅是 core，这样可以更清楚地标明哪个程序的 core 文件。

要检查一个 core 文件，像平常一样启动 gdb。不过，不需要输入 break 或 run，而是输入：

(gdb) core progname.core

如果 core 文件不在当前目录中，首先输入 dir /path/to/core/file。

调试器应该会显示如下信息：

% gdb progname
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) core progname.core
Core was generated by `progname'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x7020796d.
#0  0x164a in bazz (anint=0x5) at temp.c:17
(gdb)

在这个例子中，程序名为 progname，因此 core 文件名为 progname.core。我们可以看到程序因为尝试访问一个无法使用的内存区域而崩溃，崩溃发生在 bazz 函数中。

有时查看函数是如何被调用的很有用，因为问题可能出现在复杂程序中的调用栈的更高层。bt 命令会让 gdb 打印出调用栈的回溯信息：

(gdb) bt
#0  0x164a in bazz (anint=0x5) at temp.c:17
#1  0xefbfd888 in end ()
#2  0x162c in main () at temp.c:11
(gdb)

end() 函数在程序崩溃时被调用；在这种情况下，bazz() 函数是从 main() 被调用的。

2.6.4.4. 附加到正在运行的程序

gdb 最酷的功能之一就是它可以附加到一个已经在运行的程序。当然，这需要足够的权限才能做到这一点。一个常见的问题是，在调试一个 fork 的程序时，想要追踪子进程，但调试器只会追踪父进程。

为此，可以启动另一个 gdb，使用 ps 查找子进程的 PID，然后在 gdb 中执行：

(gdb) attach pid

然后像平常一样调试。

为了让这个过程顺利工作，调用 fork 来创建子进程的代码需要像以下这样写（摘自 gdb 的信息页面）：

...
if ((pid = fork()) < 0)		/* _Always_ check this */
	error();
else if (pid == 0) {		/* child */
	int PauseMode = 1;

	while (PauseMode)
		sleep(10);	/* 等待直到有人附加到我们 */
	...
} else {			/* parent */
	...

现在，只需附加到子进程，将 PauseMode 设置为 0，并等待 sleep() 调用返回即可！

2.7. 使用 Emacs 作为开发环境

2.7.1. Emacs

Emacs 是一个高度可定制的编辑器——事实上，它已经被定制到几乎像一个操作系统而不是编辑器的程度！许多开发者和系统管理员确实几乎把所有的时间都花在 Emacs 中，只有在注销时才会离开它。

在这里简要总结 Emacs 能做的所有事情几乎是不可能的，但以下是一些对开发者有用的功能：

• 非常强大的编辑器，支持对字符串和正则表达式（模式）进行搜索和替换，跳转到代码块的开始/结束等。

• 下拉菜单和在线帮助。

• 语言相关的语法高亮和缩进。

• 完全可定制。

• 你可以在 Emacs 中编译和调试程序。

• 当编译出错时，你可以跳转到源代码中的错误行。

• 提供一个友好的前端来使用 info 程序，阅读 GNU 超文本文档，包括 Emacs 本身的文档。

• 提供一个友好的前端来使用 gdb，允许你在程序调试时查看源代码。

当然，还有许多其他功能未被列出。

安装完成后，启动 Emacs，输入 C-h t 阅读 Emacs 教程——这意味着按住控制键，按 h 键，松开控制键，然后按 t 键。（或者，你可以使用鼠标从 Help 菜单中选择 Emacs Tutorial。）

尽管 Emacs 有菜单，但学习键绑定非常值得，因为编辑时按几个键比寻找鼠标并点击正确的地方要快得多。而且，当你与经验丰富的 Emacs 用户交谈时，你会发现他们常常随意地说出像“M-x replace-s RET foo RET bar RET”这样的表达方式，所以了解它们的意思很有用。无论如何，Emacs 有太多有用的功能，菜单栏根本容不下所有功能。

幸运的是，学习键绑定非常容易，因为它们会显示在菜单项旁边。我的建议是，首先使用菜单项打开文件，直到你了解它是如何工作的并且对其有信心，然后尝试使用 C-x C-f。当你熟悉这个操作后，再尝试其他菜单命令。

如果你记不住某个特定的键组合，可以从 Help 菜单中选择 Describe Key，然后输入它——Emacs 会告诉你它的功能。你还可以使用 Command Apropos 菜单项，查找包含某个特定单词的所有命令，旁边会显示其键绑定。

顺便说一下，前面的表达式意味着按住 Meta 键，按下 x 键，松开 Meta 键，输入 replace-s（replace-string 的缩写——Emacs 的另一个特点是你可以缩写命令），按回车键，输入 foo（你要替换的字符串），按回车键，输入 bar（你希望用来替换 foo 的字符串），再次按回车。Emacs 会执行你刚刚请求的查找和替换操作。

如果你在想 Meta 键到底是什么，它是许多 UNIX® 工作站上都有的一个特殊键。不幸的是，PC 没有这个键，因此通常使用 alt 键（如果不幸的话，使用 escape 键）。

哦，要退出 Emacs，输入 C-x C-c（这意味着按住控制键，按 x 键，按 c 键，释放控制键）。如果你有任何未保存的文件，Emacs 会询问你是否保存它们。（忽略文档中提到的 C-z 是退出 Emacs 的常用方式——那样会让 Emacs 在后台挂着，只有在没有虚拟终端的系统上才有用。）

2.7.2. 配置 Emacs

Emacs 有许多奇妙的功能；其中一些是内建的，有些则需要配置。

Emacs 并没有使用专有的宏语言来进行配置，而是使用了一种特别为编辑器改编的 Lisp 版本，称为 Emacs Lisp。如果你想学习像 Common Lisp 这样的语言，学习 Emacs Lisp 是非常有帮助的。Emacs Lisp 具有许多 Common Lisp 的特性，尽管它要小得多（因此更容易掌握）。

不过，实际上并不需要懂 Lisp 就可以开始配置 Emacs，因为我提供了一个示例 .emacs 文件，应该足以让你入门。只需将它复制到你的主目录中，并重新启动 Emacs（如果已经运行的话）；它会读取文件中的命令，并（希望）为你提供一个有用的基本设置。

2.7.3. 示例 .emacs

不幸的是，这里有太多内容需要详细解释；然而，有一两个值得一提的要点。

• 以 ; 开头的所有内容都是注释，Emacs 会忽略它们。

• 在第一行，-<strong>- Emacs-Lisp -</strong>- 是为了使我们能够在 Emacs 内部编辑 .emacs 文件，并获得所有编辑 Emacs Lisp 的高级功能。Emacs 通常会根据文件名尝试猜测这一点，但可能不会为 .emacs 文件正确识别。

• Tab 键在某些模式下绑定到缩进功能，因此当你按下 Tab 键时，它会缩进当前的代码行。如果你想在写的内容中插入一个 Tab 字符，可以在按 Tab 键时按住控制键。

• 该文件支持 C、C++、Perl、Lisp 和 Scheme 的语法高亮，通过从文件名猜测语言来启用。

• Emacs 已经有一个预定义的函数 next-error。在编译输出窗口中，它允许你通过执行 M-n 从一个编译错误跳到下一个；我们定义了一个互补函数 previous-error，允许你通过执行 M-p 跳转到前一个错误。最好的功能是，C-c C-c 会打开发生错误的源文件并跳转到相应的行。

• 我们启用 Emacs 的服务器功能，这样，如果你在 Emacs 之外做一些事情，想要编辑一个文件，只需输入

  复制

  % emacsclient filename

示例 1 .emacs

;; -*-Emacs-Lisp-*-

;; This file is designed to be re-evaled; use the variable first-time
;; to avoid any problems with this.
(defvar first-time t
  "Flag signifying this is the first time that .emacs has been evaled")

;; Meta
(global-set-key "\M- " 'set-mark-command)
(global-set-key "\M-\C-h" 'backward-kill-word)
(global-set-key "\M-\C-r" 'query-replace)
(global-set-key "\M-r" 'replace-string)
(global-set-key "\M-g" 'goto-line)
(global-set-key "\M-h" 'help-command)

;; Function keys
(global-set-key [f1] 'manual-entry)
(global-set-key [f2] 'info)
(global-set-key [f3] 'repeat-complex-command)
(global-set-key [f4] 'advertised-undo)
(global-set-key [f5] 'eval-current-buffer)
(global-set-key [f6] 'buffer-menu)
(global-set-key [f7] 'other-window)
(global-set-key [f8] 'find-file)
(global-set-key [f9] 'save-buffer)
(global-set-key [f10] 'next-error)
(global-set-key [f11] 'compile)
(global-set-key [f12] 'grep)
(global-set-key [C-f1] 'compile)
(global-set-key [C-f2] 'grep)
(global-set-key [C-f3] 'next-error)
(global-set-key [C-f4] 'previous-error)
(global-set-key [C-f5] 'display-faces)
(global-set-key [C-f8] 'dired)
(global-set-key [C-f10] 'kill-compilation)

;; Keypad bindings
(global-set-key [up] "\C-p")
(global-set-key [down] "\C-n")
(global-set-key [left] "\C-b")
(global-set-key [right] "\C-f")
(global-set-key [home] "\C-a")
(global-set-key [end] "\C-e")
(global-set-key [prior] "\M-v")
(global-set-key [next] "\C-v")
(global-set-key [C-up] "\M-\C-b")
(global-set-key [C-down] "\M-\C-f")
(global-set-key [C-left] "\M-b")
(global-set-key [C-right] "\M-f")
(global-set-key [C-home] "\M-<")
(global-set-key [C-end] "\M->")
(global-set-key [C-prior] "\M-<")
(global-set-key [C-next] "\M->")

;; Mouse
(global-set-key [mouse-3] 'imenu)

;; Misc
(global-set-key [C-tab] "\C-q\t")	; Control tab quotes a tab.
(setq backup-by-copying-when-mismatch t)

;; Treat 'y' or <CR> as yes, 'n' as no.
(fset 'yes-or-no-p 'y-or-n-p)
(define-key query-replace-map [return] 'act)
(define-key query-replace-map [?\C-m] 'act)

;; Load packages
(require 'desktop)
(require 'tar-mode)

;; Pretty diff mode
(autoload 'ediff-buffers "ediff" "Intelligent Emacs interface to diff" t)
(autoload 'ediff-files "ediff" "Intelligent Emacs interface to diff" t)
(autoload 'ediff-files-remote "ediff"
  "Intelligent Emacs interface to diff")

(if first-time
    (setq auto-mode-alist
	  (append '(("\\.cpp$" . c++-mode)
		    ("\\.hpp$" . c++-mode)
		    ("\\.lsp$" . lisp-mode)
		    ("\\.scm$" . scheme-mode)
		    ("\\.pl$" . perl-mode)
		    ) auto-mode-alist)))

;; Auto font lock mode
(defvar font-lock-auto-mode-list
  (list 'c-mode 'c++-mode 'c++-c-mode 'emacs-lisp-mode 'lisp-mode 'perl-mode 'scheme-mode)
  "List of modes to always start in font-lock-mode")

(defvar font-lock-mode-keyword-alist
  '((c++-c-mode . c-font-lock-keywords)
    (perl-mode . perl-font-lock-keywords))
  "Associations between modes and keywords")

(defun font-lock-auto-mode-select ()
  "Automatically select font-lock-mode if the current major mode is in font-lock-auto-mode-list"
  (if (memq major-mode font-lock-auto-mode-list)
      (progn
	(font-lock-mode t))
    )
  )

(global-set-key [M-f1] 'font-lock-fontify-buffer)

;; New dabbrev stuff
;(require 'new-dabbrev)
(setq dabbrev-always-check-other-buffers t)
(setq dabbrev-abbrev-char-regexp "\\sw\\|\\s_")
(add-hook 'emacs-lisp-mode-hook
	  '(lambda ()
	     (set (make-local-variable 'dabbrev-case-fold-search) nil)
	     (set (make-local-variable 'dabbrev-case-replace) nil)))
(add-hook 'c-mode-hook
	  '(lambda ()
	     (set (make-local-variable 'dabbrev-case-fold-search) nil)
	     (set (make-local-variable 'dabbrev-case-replace) nil)))
(add-hook 'text-mode-hook
	  '(lambda ()
	     (set (make-local-variable 'dabbrev-case-fold-search) t)
	     (set (make-local-variable 'dabbrev-case-replace) t)))

;; C++ and C mode...
(defun my-c++-mode-hook ()
  (setq tab-width 4)
  (define-key c++-mode-map "\C-m" 'reindent-then-newline-and-indent)
  (define-key c++-mode-map "\C-ce" 'c-comment-edit)
  (setq c++-auto-hungry-initial-state 'none)
  (setq c++-delete-function 'backward-delete-char)
  (setq c++-tab-always-indent t)
  (setq c-indent-level 4)
  (setq c-continued-statement-offset 4)
  (setq c++-empty-arglist-indent 4))

(defun my-c-mode-hook ()
  (setq tab-width 4)
  (define-key c-mode-map "\C-m" 'reindent-then-newline-and-indent)
  (define-key c-mode-map "\C-ce" 'c-comment-edit)
  (setq c-auto-hungry-initial-state 'none)
  (setq c-delete-function 'backward-delete-char)
  (setq c-tab-always-indent t)
;; BSD-ish indentation style
  (setq c-indent-level 4)
  (setq c-continued-statement-offset 4)
  (setq c-brace-offset -4)
  (setq c-argdecl-indent 0)
  (setq c-label-offset -4))

;; Perl mode
(defun my-perl-mode-hook ()
  (setq tab-width 4)
  (define-key c++-mode-map "\C-m" 'reindent-then-newline-and-indent)
  (setq perl-indent-level 4)
  (setq perl-continued-statement-offset 4))

;; Scheme mode...
(defun my-scheme-mode-hook ()
  (define-key scheme-mode-map "\C-m" 'reindent-then-newline-and-indent))

;; Emacs-Lisp mode...
(defun my-lisp-mode-hook ()
  (define-key lisp-mode-map "\C-m" 'reindent-then-newline-and-indent)
  (define-key lisp-mode-map "\C-i" 'lisp-indent-line)
  (define-key lisp-mode-map "\C-j" 'eval-print-last-sexp))

;; Add all of the hooks...
(add-hook 'c++-mode-hook 'my-c++-mode-hook)
(add-hook 'c-mode-hook 'my-c-mode-hook)
(add-hook 'scheme-mode-hook 'my-scheme-mode-hook)
(add-hook 'emacs-lisp-mode-hook 'my-lisp-mode-hook)
(add-hook 'lisp-mode-hook 'my-lisp-mode-hook)
(add-hook 'perl-mode-hook 'my-perl-mode-hook)

;; Complement to next-error
(defun previous-error (n)
  "Visit previous compilation error message and corresponding source code."
  (interactive "p")
  (next-error (- n)))

;; Misc...
(transient-mark-mode 1)
(setq mark-even-if-inactive t)
(setq visible-bell nil)
(setq next-line-add-newlines nil)
(setq compile-command "make")
(setq suggest-key-bindings nil)
(put 'eval-expression 'disabled nil)
(put 'narrow-to-region 'disabled nil)
(put 'set-goal-column 'disabled nil)
(if (>= emacs-major-version 21)
	(setq show-trailing-whitespace t))

;; Elisp archive searching
(autoload 'format-lisp-code-directory "lispdir" nil t)
(autoload 'lisp-dir-apropos "lispdir" nil t)
(autoload 'lisp-dir-retrieve "lispdir" nil t)
(autoload 'lisp-dir-verify "lispdir" nil t)

;; Font lock mode
(defun my-make-face (face color &optional bold)
  "Create a face from a color and optionally make it bold"
  (make-face face)
  (copy-face 'default face)
  (set-face-foreground face color)
  (if bold (make-face-bold face))
  )

(if (eq window-system 'x)
    (progn
      (my-make-face 'blue "blue")
      (my-make-face 'red "red")
      (my-make-face 'green "dark green")
      (setq font-lock-comment-face 'blue)
      (setq font-lock-string-face 'bold)
      (setq font-lock-type-face 'bold)
      (setq font-lock-keyword-face 'bold)
      (setq font-lock-function-name-face 'red)
      (setq font-lock-doc-string-face 'green)
      (add-hook 'find-file-hooks 'font-lock-auto-mode-select)

      (setq baud-rate 1000000)
      (global-set-key "\C-cmm" 'menu-bar-mode)
      (global-set-key "\C-cms" 'scroll-bar-mode)
      (global-set-key [backspace] 'backward-delete-char)
					;      (global-set-key [delete] 'delete-char)
      (standard-display-european t)
      (load-library "iso-transl")))

;; X11 or PC using direct screen writes
(if window-system
    (progn
      ;;      (global-set-key [M-f1] 'hilit-repaint-command)
      ;;      (global-set-key [M-f2] [?\C-u M-f1])
      (setq hilit-mode-enable-list
	    '(not text-mode c-mode c++-mode emacs-lisp-mode lisp-mode
		  scheme-mode)
	    hilit-auto-highlight nil
	    hilit-auto-rehighlight 'visible
	    hilit-inhibit-hooks nil
	    hilit-inhibit-rebinding t)
      (require 'hilit19)
      (require 'paren))
  (setq baud-rate 2400)			; For slow serial connections
  )

;; TTY type terminal
(if (and (not window-system)
	 (not (equal system-type 'ms-dos)))
    (progn
      (if first-time
	  (progn
	    (keyboard-translate ?\C-h ?\C-?)
	    (keyboard-translate ?\C-? ?\C-h)))))

;; Under UNIX
(if (not (equal system-type 'ms-dos))
    (progn
      (if first-time
	  (server-start))))

;; Add any face changes here
(add-hook 'term-setup-hook 'my-term-setup-hook)
(defun my-term-setup-hook ()
  (if (eq window-system 'pc)
      (progn
;;	(set-face-background 'default "red")
	)))

;; Restore the "desktop" - do this as late as possible
(if first-time
    (progn
      (desktop-load-default)
      (desktop-read)))

;; Indicate that this file has been read at least once
(setq first-time nil)

;; No need to debug anything now

(setq debug-on-error nil)

;; All done
(message "All done, %s%s" (user-login-name) ".")

2.7.4. 扩展 Emacs 支持的语言范围

如果你只想在 .emacs 中使用已经支持的语言（C、C++、Perl、Lisp 和 Scheme），那是很好，但如果有一种新的语言叫做 "whizbang" 出现，充满了激动人心的功能，该怎么办呢？

首先要做的是查看 whizbang 是否附带了任何可以让 Emacs 了解该语言的文件。通常这些文件的扩展名是 .el，即 "Emacs Lisp" 的缩写。例如，如果 whizbang 是一个 FreeBSD port，我们可以通过以下命令来查找这些文件：

% find /usr/ports/lang/whizbang -name "*.el" -print

然后将这些文件复制到 Emacs 的 site-lisp 目录中进行安装。在 FreeBSD 中，site-lisp 目录是 /usr/local/share/emacs/site-lisp。

例如，如果 find 命令的输出是：

/usr/ports/lang/whizbang/work/misc/whizbang.el

那么我们应该执行：

# cp /usr/ports/lang/whizbang/work/misc/whizbang.el /usr/local/share/emacs/site-lisp

接下来，我们需要决定 whizbang 源文件的扩展名是什么。假设它们都以 .wiz 结尾。我们需要在 .emacs 中添加一条记录，确保 Emacs 能够使用 whizbang.el 中的信息。

找到 .emacs 中的 auto-mode-alist 条目，然后添加一行，如下所示：

...
("\\.lsp$" . lisp-mode)
("\\.wiz$" . whizbang-mode)
("\\.scm$" . scheme-mode)
...

这意味着当你编辑一个以 .wiz 结尾的文件时，Emacs 会自动进入 whizbang-mode。

接下来，在 .emacs 中找到 font-lock-auto-mode-list 条目。像这样将 whizbang-mode 添加到其中：

;; 自动字体锁定模式
(defvar font-lock-auto-mode-list
  (list 'c-mode 'c++-mode 'c++-c-mode 'emacs-lisp-mode 'whizbang-mode 'lisp-mode 'perl-mode 'scheme-mode)
  "始终启用字体锁定模式的模式列表")

这意味着当编辑一个 .wiz 文件时，Emacs 会始终启用 font-lock-mode（即语法高亮）。

就这样，完成了所有必要的设置。如果你希望在打开 .wiz 文件时自动执行其他操作，可以添加一个 whizbang-mode hook（参见 my-scheme-mode-hook，这是一个简单的例子，添加了 auto-indent）。

2.8. 进一步阅读

• Brian Harvey 和 Matthew Wright Simply Scheme MIT 1994. ISBN 0-262-08226-8

• Randall Schwartz Learning Perl O’Reilly 1993 ISBN 1-56592-042-2

• Patrick Henry Winston 和 Berthold Klaus Paul Horn Lisp (3rd Edition) Addison-Wesley 1989 ISBN 0-201-08319-1

• Brian W. Kernighan 和 Rob Pike The Unix Programming Environment Prentice-Hall 1984 ISBN 0-13-937681-X

• Brian W. Kernighan 和 Dennis M. Ritchie The C Programming Language (2nd Edition) Prentice-Hall 1988 ISBN 0-13-110362-8

• Bjarne Stroustrup The C++ Programming Language Addison-Wesley 1991 ISBN 0-201-53992-6

• W. Richard Stevens Advanced Programming in the Unix Environment Addison-Wesley 1992 ISBN 0-201-56317-7

• W. Richard Stevens Unix Network Programming Prentice-Hall 1990 ISBN 0-13-949876-1

1.1. 在 FreeBSD 上进行开发

我们现在准备开始了。系统已经安装好，你也准备开始编程了。但是从哪里开始呢？FreeBSD 提供了什么？作为程序员，它能为我做什么？

本章试图回答这些问题。当然，像其他任何技能一样，编程也有不同的熟练程度。对一些人来说，这是业余爱好；对另一些人来说，这是职业。本章的信息可能更偏向初学者；事实上，它对那些不熟悉 FreeBSD 平台的程序员可能非常有帮助。

1.2. BSD 的愿景

打造最佳的类 UNIX® 操作系统套件，既尊重最初的软件工具理念，也兼顾可用性、性能与稳定性。

1.3. 架构指导方针

我们的理念可通过以下指导方针来描述：

• 除非实现者无法完成一个真实的应用，否则不要添加新功能。

• 明确一个系统不是什么，与定义它是什么同样重要。不要试图满足全世界的所有需求；相反，应使系统具有可扩展性，以便以向后兼容的方式满足额外需求。

• 唯一比根据一个例子泛化更糟的，是在没有任何例子的情况下泛化。

• 如果一个问题尚未完全理解，最好根本不要提供解决方案。

• 如果用 10% 的工作量就能实现 90% 的效果，那就选更简单的方案。

• 尽可能将复杂性隔离开来。

• 提供机制，而不是政策。特别是，将用户界面策略交给客户端掌控。

摘自 Scheifler 与 Gettys：《X Window System》

1.4. /usr/src 的结构

该章节记录了 FreeBSD 源码树中施行的各种指南和政策。

5.1. 编码风格指南

5.2. Makefile 中的 MAINTAINER

如果 FreeBSD src/ 分发中的某个部分由某个人或一组人维护，这会通过 src/MAINTAINERS 文件中的一条记录来表达。Ports Collection 中某个 Port 的维护者通过在该 Port 的 Makefile 中添加一行 MAINTAINER 来向外界表明其维护权：

技巧

对于仓库中的其他部分，或没有指定维护者的部分，或当你不确定谁是活跃的维护者时，可以尝试查看源码树相关部分的最近提交历史。很多时候，并没有明确指定某个维护者，但过去几年中持续活跃于某个源码树部分的人通常也愿意审阅更改。即使文档或源码中没有特别说明，请求审阅作为一种礼貌行为也是非常合理的。

维护者的职责如下：

• 维护者拥有该代码的所有权，并对其负责。这意味着他/她需要修复与该部分代码相关的 bug 并回应问题报告；如果是引入的第三方软件，还需按需跟踪新版本。

• 如果某个目录指定了维护者，那么对该目录的更改在提交前应送审给维护者。只有在多次发送邮件仍长时间未收到回复时，才可在未经审阅的情况下提交。但建议尽可能还是请其他人进行审阅。

• 当然，未经同意不能将某个人或团队添加为维护者。另一方面，维护者不必是 committer，也可以是一个团队。

5.3. 引入的软件（Contributed Software）

管理引入软件的标准做法是创建一个 vendor 分支，在该分支中可以以“干净”方式导入软件（即不加修改），并以版本控制的方式跟踪更新。然后将 vendor 分支中的内容应用到源码树中，并可进行本地修改。FreeBSD 专属的构建集成代码应保存在源码树中，而非 vendor 分支中。

引入软件通常放置在源码树的 contrib/ 子目录中，也有一些例外。仅由内核使用的引入软件位于 sys/contrib/ 之下。

注意

由于会增加后续版本导入的难度，因此在仍然跟踪 vendor 分支的文件上，强烈不建议 进行次要的、无关紧要的或纯粹为美观的修改。

5.3.1. Vendor 导入

5.4. 受限文件（Encumbered Files）

有时可能需要将受限文件添加到 FreeBSD 源码树中。例如，如果某个设备在运行前需要加载一段我们没有源代码的小型二进制代码，那么这个二进制文件就被视为受限文件。下面是将受限文件纳入 FreeBSD 源码树所需遵循的政策：

1. 任何由系统 CPU 执行或解释、且不是源代码格式的文件都属于受限文件。

2. 任何授权比 BSD 或 GNU 更严格的文件都属于受限文件。

3. 包含供硬件使用的可下载二进制数据的文件不被视为受限文件，除非第 (1) 或 (2) 条适用于它。

5. 受限文件应放在 src/contrib 或 src/sys/contrib。

6. 整个模块应保持完整。除非与非受限代码有代码共享，否则无需拆分。

7. 过去二进制文件通常是 uuencode 编码的，并命名为 arch/filename.o.uu。这已不再必要，现在可以直接将二进制文件原样加入仓库。

8. 内核文件：

   1. 应始终在 conf/files.* 中列出（为简化构建）。

   3. 是否纳入发行版由 Release Engineer 决定。

9. 用户态文件：

5.5. 共享库

如果你要为某个 Port 或其他软件添加共享库支持，而该软件原本并不使用共享库，那么其版本号应遵循以下规则。通常，这些版本号与软件的发行版本无关。

对于 Port：

• 优先使用上游已经指定的版本号。

• 如果上游提供了符号版本控制（symbol versioning），应确保我们也使用其脚本。

对于 base 系统：

• 库版本号从 1 开始。

• 强烈建议为新库添加符号版本控制。

• 若存在不兼容的更改，应使用符号版本控制并保持向后 ABI 兼容性。

• 如果无法做到这一点，或者库没有使用符号版本控制，则需要提升库的版本号。

• 若需提升 symbol-versioned 库的版本号，必须事先与 Release Engineering 团队协商，说明为何这一更改如此重要，以致必须突破 ABI 兼容限制。

例如，添加函数或修复接口不变的 bug 都可以接受；但删除函数、改变函数调用语法等行为要么需要提供向后兼容的符号版本，要么需要提升主版本号。

更改库版本是提交者的责任。

ELF 动态链接器会精确匹配库名。目前的流行做法是将库名设为 libexample.so.x.y，其中 x 为主版本号，y 为次版本号。惯例是将库的 soname（ELF 中的 DT_SONAME 标签）设为 libexample.so.x，并在安装时建立符号链接：libexample.so.x → libexample.so.x.y，libexample.so → libexample.so.x。这样，静态链接器在使用 -lexample 选项时，会自动链接到正确的库。几乎所有流行的构建系统都会自动采用这种方式。

7.1. 概述

BSD socket 将进程间通信提升到了一个新的层次。通信的进程不再必须运行在同一台机器上。它们可以运行在同一台机器上，但不再是必须的。

不仅如此，这些进程也不需要运行在相同的操作系统下。多亏了 BSD socket，你的 FreeBSD 软件可以顺利地与一台 Macintosh® 上运行的程序协作，与一台 Sun™ 工作站上的程序协作，甚至与一台运行 Windows® 2000 的程序协作，所有这些通过基于以太网的局域网连接在一起。

而你的软件同样可以与运行在另一栋楼、另一个大陆、甚至潜艇或航天飞机中的进程协作。

它也可以与不是计算机（至少不是严格意义上的计算机）中的进程协作，比如打印机、数码相机、医疗设备等设备中的进程。几乎任何能进行数字通信的东西。

7.2. 网络与多样性

我们已经暗示过网络的多样性。许多不同的系统必须彼此通信。而它们必须讲相同的语言。它们还必须以相同的方式理解这种语言。

人们常常以为肢体语言是通用的。但事实并非如此。在我十几岁的时候，我父亲带我去了保加利亚。我们在索非亚的一座公园里坐在一张桌边，一个小贩走近我们，试图卖我们一些烤杏仁。

那时我还没怎么学过保加利亚语，于是，我没有说“不”，而是左右摇头，这是“不”这个意思的“通用”肢体语言。结果小贩立刻开始给我们装杏仁。

这时我才记起有人告诉过我，在保加利亚，摇头表示“是”。我赶紧改为上下点头。小贩注意到了，拿起杏仁，离开了。对一个不知情的旁观者来说，我的肢体语言没有变化：我继续摇头点头。变的是肢体语言的含义。起初，小贩和我对相同的语言作出了完全不同的解释。我必须调整自己对这种语言的解释，才能让小贩理解。

计算机之间也是如此：相同的符号可能具有不同，甚至完全相反的含义。因此，两个计算机要能互相理解，不仅要使用相同的语言，还要以相同的方式解释这种语言。

7.3. 协议

尽管各种编程语言通常具有复杂的语法，并使用许多多字母的保留字（这使得它们对程序员更易于理解），数据通信的语言通常非常简洁。它们不使用多字节的单词，而是经常使用单个的比特。这样做有一个非常令人信服的理由：虽然数据在计算机内部的传输速度接近光速，但在两台计算机之间的传输速度往往要慢得多。

由于数据通信中使用的语言非常简洁，我们通常将其称为协议，而不是语言。

当数据从一台计算机传输到另一台计算机时，它总是使用多个协议。这些协议是分层的。数据可以比作洋葱的内部：你需要剥去几层“皮”才能获得数据。用一张图片来说明这一点会更好：

图 1. 协议层

在这个例子中，我们正在尝试从一个通过以太网连接的网页中获取一张图片。

图片由原始数据组成，原始数据只是一个 RGB 值的序列，我们的软件可以处理这些值，即将其转换为图像并显示在显示器上。

遗憾的是，我们的软件无法知道这些原始数据是如何组织的：它是 RGB 值的序列，还是灰度强度的序列，或者是 CMYK 编码的颜色？数据是用 8 位量表示，还是 16 位，或者是 4 位？图片由多少行和列组成？某些像素是否需要透明？

我想你已经明白了……

为了告诉我们的软件如何处理这些原始数据，它被编码为 PNG 文件。它也可以是 GIF 文件，或者 JPEG 文件，但它是 PNG。

而 PNG 就是一个协议。

在这个时候，我听到有些人喊道：“不，它不是！它是文件格式！”

当然，它是文件格式。但从数据通信的角度来看，文件格式就是协议：文件结构是一个语言，它简洁到极点，告诉我们的进程数据是如何组织的。因此，它是一个协议。

然而，如果我们收到的只是 PNG 文件，我们的软件将面临一个严重的问题：它怎么知道数据表示的是图像，而不是某些文本，或者是音频，或者其他什么？其次，怎么知道图像是 PNG 格式而不是 GIF、JPEG 或其他图像格式？

为了获得这些信息，我们使用了另一个协议：HTTP。这个协议可以准确地告诉我们，数据表示的是图像，并且它使用的是 PNG 协议。它还可以告诉我们其他信息，但我们现在还是集中在协议层次上。

所以，现在我们收到了一个包裹在 PNG 协议中的数据，再包裹在 HTTP 协议中。那我们是如何从服务器获得它的呢？

是通过 Ethernet 上的 TCP/IP 来的，实际上那是三个协议。为了更容易解释接下来的内容，我现在将重点讲解 Ethernet。

以太网是一个有趣的局域网（LAN）计算机连接系统。每台计算机都有一个网络接口卡（NIC），该卡具有一个唯一的 48 位 ID，称为地址。世界上没有两台 Ethernet NIC 拥有相同的地址。

这些 NIC 彼此连接。当一台计算机想要与同一 Ethernet LAN 中的另一台计算机通信时，它会通过网络发送消息。每个 NIC 都能看到这条消息。但作为以太网协议的一部分，数据中包含了目标 NIC 的地址（以及其他信息）。因此，只有其中一块网络接口卡会注意到这条消息，其他的都会忽略它。

但并不是所有的计算机都连接在同一个网络上。仅仅因为我们通过以太网接收到数据，并不意味着它来自我们自己的局域网。它可能来自其他通过 Internet 连接的网络（可能并非基于以太网的网络）。

所有数据通过互联网传输都使用 IP，即互联网协议。它的基本作用是告诉我们数据来自哪里，应该到达哪里。它不保证我们会收到数据，只是保证如果我们收到了数据，我们会知道它来自哪里。

即使我们收到了数据，IP 也不保证我们会按发送方发送的顺序接收到不同的数据块。例如，我们可能会先收到图像的中央部分，然后才收到左上角，或者右下角。

正是 TCP（传输控制协议）要求发送方重新发送任何丢失的数据，并将所有数据按正确的顺序排列。

总之，从一台计算机传输到另一台计算机，告诉它一张图像是什么样子的，竟然用了五个不同的协议。我们收到了包裹在 PNG 协议中的数据，再包裹在 HTTP 协议中，再包裹在 TCP 协议中，再包裹在 IP 协议中，最后包裹在以太网协议中。

哦，顺便说一句，可能还有许多其他协议参与了这个过程。例如，如果我们的局域网通过拨号连接到 Internet，那么它就用了 PPP 协议，通过调制解调器传输，调制解调器又使用了一个（或多个）不同的调制解调协议，等等，等等……

作为开发人员，你现在应该会问：“我该如何处理这一切？”

幸运的是，你并不需要处理所有这些内容。你需要处理其中的一部分，但不是全部。具体来说，你不必担心物理连接（在我们这个例子中是 Ethernet 和可能的 PPP 等）。你也不必处理互联网协议或传输控制协议。

换句话说，你不需要做任何事情来接收来自另一台计算机的数据。嗯，你确实需要请求它，但这几乎就像打开一个文件一样简单。

一旦你接收到数据，就由你来决定如何处理它。在我们的例子中，你需要理解 HTTP 协议和 PNG 文件结构。

举个比喻，所有的网络协议变成了一个灰色地带：这不仅仅是因为我们不理解它是如何工作的，而是因为我们不再关注它。套接字接口为我们处理了这一灰色地带：

图 2. 套接字覆盖的协议层

我们只需要理解任何告诉我们如何解释数据的协议，而不是如何从另一个进程接收数据，或如何发送数据到另一个进程。

7.4. 套接字模型

BSD 套接字是建立在基本 UNIX® 模型之上的：一切皆文件。在我们的例子中，套接字可以让我们接收一个HTTP 文件，可以这么说。然后，剩下的工作就是从中提取出PNG 文件。

由于互联网的复杂性，我们不能简单地使用 open 系统调用或 open() C 函数。相反，我们需要采取多个步骤来“打开”一个套接字。

然而，一旦我们完成这些步骤，我们就可以开始像处理任何文件描述符一样处理套接字：我们可以从中read、write、pipe，最后close它。

7.5. 必要的套接字函数

虽然 FreeBSD 提供了多种函数来操作套接字，但我们只需要四个来“打开”一个套接字。在某些情况下，我们甚至只需要两个。

7.5.1. 客户端与服务器的区别

通常，套接字数据通信的一端是服务器，另一端是客户端。

7.5.1.1. 共同的元素

7.5.1.1.1. socket

返回值与 open 相同，都是整数。FreeBSD 从与文件句柄相同的池中分配它的值。这使得套接字可以像文件一样被处理。

domain 参数告诉系统你希望使用的协议族。有许多协议族，其中一些是厂商特定的，其他的则是常见的。它们在 sys/socket.h 中声明。

对于 UDP、TCP 和其他 Internet 协议（IPv4），使用 PF_INET。

type 参数有五个定义的值，也在 sys/socket.h 中声明。所有这些值都以 “SOCK_” 开头。最常见的是 SOCK_STREAM，它告诉系统你请求一个可靠的流式传输服务（与 PF_INET 一起使用时是 TCP）。

如果你请求的是 SOCK_DGRAM，你将请求一个无连接的数据报传输服务（在我们的例子中是 UDP）。

如果你想控制底层协议（如 IP），甚至是网络接口（如以太网），你需要指定 SOCK_RAW。

最后，protocol 参数取决于前两个参数，并非总是有意义。在这种情况下，可以将其值设置为 0。

注意

未连接的套接字在 socket 函数中，我们并没有指定该套接字要连接到哪个其他系统。我们新创建的套接字仍然是未连接的。这是故意的：用电话的类比来说，我们刚刚将调制解调器接入电话线。我们既没有告诉调制解调器拨打电话，也没有告诉它在电话响起时接听。

7.5.1.1.2. sockaddr

各种套接字系列的函数期望得到（或使用 C 术语的指针）内存中一小块区域的地址。这些 C 声明在 sys/socket.h 中将其称为 struct sockaddr。这个结构在同一个文件中声明：

请注意 sa_data 字段的模糊性，它仅声明为 14 字节的数组，注释提示它可能包含超过 14 字节的数据。

这种模糊性是故意的。套接字是一个非常强大的接口。虽然大多数人可能认为它不过是一个 Internet 接口——并且大多数应用程序现在可能就是这样使用它——套接字几乎可以用于任何形式的进程间通信，其中互联网（或更确切地说是 IP）只是其中之一。

sys/socket.h 将套接字所处理的各种协议称为地址族，并在 sockaddr 定义之前列出它们：

用于 IP 的是 AF_INET，它是常量 2 的符号表示。

正是 sockaddr 中列出的 地址族 决定了如何使用 sa_data 字段中那些模糊命名的字节。

具体来说，当地址族为 AF_INET 时，我们可以在需要 sockaddr 的地方使用 netinet/in.h 中的 struct sockaddr_in：

我们可以通过以下方式可视化它的组织结构：

图 3. sockaddr_in 结构

三个重要的字段是 sin_family，它是结构的第 1 字节；sin_port，它是 16 位的值，存储在第 2 和第 3 字节中；以及 sin_addr，它是一个 32 位的 IP 地址整数表示，存储在第 4 至第 7 字节中。

现在，让我们尝试填充它。假设我们正在为 daytime 协议编写客户端，该协议简单地规定其服务器会将当前的日期和时间的文本字符串写入端口 13。我们希望使用 TCP/IP，因此我们需要在地址族字段中指定 AF_INET。AF_INET 被定义为 2。让我们使用 IP 地址 192.43.244.18，这是美国联邦政府的时间服务器（time.nist.gov）。

图 4. sockaddr_in 的具体示例

顺便提一下，sin_addr 字段被声明为 struct in_addr 类型，它在 netinet/in.h 中定义：

此外，in_addr_t 是一个 32 位的整数。

192.43.244.18 只是通过列出其所有 8 位字节（从最重要的字节开始）来表示一个 32 位整数的便捷表示法。

到目前为止，我们已经将 sockaddr 视为一种抽象。我们的计算机并不会将 short 整数存储为单一的 16 位实体，而是作为一系列的 2 个字节。类似地，它将 32 位整数存储为一系列 4 个字节。

假设我们编写了如下代码：

结果会是什么样子呢？

当然，这取决于具体的计算机系统。在一个奔腾或其他 x86 系统上，它会像这样显示：

图 5. 在 Intel 系统上的 sockaddr_in

在不同的系统上，可能会是这样的：

图 6. 在 MSB 系统上的 sockaddr_in

在 PDP 上，它的表现可能又会不同。但上述两种方式是如今最常见的两种实现方式。

通常，为了编写可移植的代码，程序员会假装这些差异并不存在。而他们确实也能蒙混过关（除非他们在写汇编语言）。不过，当你在为 sockets 编程时，你就不能这么轻松地蒙混过关了。

为什么？

因为在与另一台计算机通信时，你通常不知道它是以 最高有效字节（MSB）优先还是 最低有效字节（LSB）优先来存储数据的。

你可能会想，“那 sockets 难道不会替我处理这些吗？”

不会。

这个答案可能一开始让你感到惊讶，但请记住，通用的 sockets 接口只理解 sockaddr 结构中的 sa_len 和 sa_family 字段。你不必担心这些字段的字节序（当然，在 FreeBSD 上 sa_family 反正只有 1 个字节，但许多其他 UNIX® 系统没有 sa_len 字段，并且使用 2 字节的 sa_family 字段，并且期望数据以该计算机的本地顺序存储）。

但对 sockets 而言，其余的数据就只是 sa_data[14]。根据 地址族 的不同，sockets 只是将这些数据转发到目标地。

事实上，当我们输入一个端口号时，是为了让另一台计算机知道我们请求的是什么服务。而当我们是服务器时，我们读取端口号，是为了知道对方期望我们提供什么服务。无论是哪种情况，sockets 只是将端口号当作数据转发。它不会对其进行任何解释。

同样，我们输入 IP 地址，是为了告诉网络上的所有中间设备数据应该被送往何处。sockets 依旧只是将其当作数据转发。

这就是为什么，我们（程序员，而不是 sockets）必须区分我们的计算机使用的字节序与用于发送给另一台计算机的标准字节序。

我们称我们的计算机使用的字节序为 主机字节序，简称 主机序。

而在 IP 上传送多字节数据有一个约定，就是以 MSB 优先 的方式传送。我们称这种顺序为 网络字节序，简称 网络序。

现在，如果我们将上面的代码编译为运行在 Intel 架构的计算机上，我们的 主机字节序 将会产生如下结果：

图 7. Intel 系统上的主机字节序

但 网络字节序 要求我们以 MSB 优先的方式存储数据：

图 8. 网络字节序

不幸的是，我们的 主机序 与 网络序 完全相反。

我们有几种方式可以应对这种情况。其中一种方法是在代码中 反转 这些值：

这样可以“骗过”我们的编译器，让它以 网络字节序 存储这些数据。在某些情况下，这确实是正确的做法（比如当你在写汇编语言的时候）。但在大多数情况下，这会引起问题。

假设你用 C 写了一个基于 sockets 的程序。你知道它会运行在奔腾上，于是你将所有常量反转后强行设为 网络字节序。一切正常。

直到有一天，你信赖的旧奔腾变成了锈迹斑斑的老古董。你换了一台新机器，它的 主机序 正好和 网络序 一致。你重新编译了你的所有软件。所有程序都运作良好，除了你那一个程序。

你已经忘了当初你曾经强行把所有常量写成了和 主机序 相反的顺序。你开始拔头发，呼唤你听过和没听过的所有神的名字，用海绵棒猛击显示器，进行各种传统的“调试祭祀仪式”，试图搞清楚为什么一个一直工作良好的程序突然就失效了。

最终，你搞清楚了问题的根源，骂了几句脏话，然后开始重写你的代码。

在 MSB 优先 的系统上，这些函数不会进行任何操作。而在 LSB 优先 的系统上，它们会将值转换为正确的顺序。

所以，无论你的软件是在哪个系统上编译的，只要使用这些函数，你的数据最终就会以正确的顺序被传送出去。

7.5.1.2. 客户端函数

通常，客户端负责发起与服务器的连接。客户端知道它要联系哪个服务器：它知道服务器的 IP 地址，也知道服务器所监听的 端口。这就像你拿起电话拨号（这个 地址），然后在有人接听后请求找负责“wingdings”的人（这个 端口）。

7.5.1.2.1. connect

参数 s 是 socket，也就是 socket 函数返回的值。name 是一个指向 sockaddr 的指针，我们前面已经详细讨论过该结构。最后，namelen 用于告知系统我们的 sockaddr 结构体的字节数。

如果 connect 调用成功，它会返回 0。否则返回 -1，并将错误代码存储在 errno 中。

connect 可能失败的原因有很多。例如，在尝试连接到某个互联网地址时，对方的 IP 地址可能根本不存在，或者对方主机宕机了，或者太忙，或者根本没有在指定端口监听任何服务。也有可能直接 拒绝 来自特定代码的任何请求。

7.5.1.2.2. 我们的第一个客户端

现在我们已经掌握足够知识，来编写一个非常简单的客户端程序，它将从 192.43.244.18 获取当前时间并打印到 stdout。

现在请打开编辑器，输入上述内容，保存为 daytime.c，然后编译并运行它：

在本例中，日期是 2001 年 6 月 19 日，时间是 UTC 时间 02:29:25。当然，你运行程序时的输出会有所不同。

7.5.1.3. 服务器函数

典型的服务器不会主动发起连接。它会等待客户端来调用它、请求服务。它不知道客户端什么时候会来，也不知道会有多少客户端会来。有时候它只是静静地坐在那里等待，而下一刻，可能就会突然被大量同时请求的客户端淹没。

sockets 接口提供了三个基本函数来处理这一情况。

7.5.1.3.1. bind

端口就像电话线路上的分机：拨通一个号码后，还需要拨分机号才能联系到特定的人或部门。

除了在 addr 中指定端口，服务器也可以包括它自己的 IP 地址。然而，它也可以使用符号常量 INADDR_ANY 来表示将接收发往该端口的所有请求，而不管目标 IP 是什么。这个符号常量和其他几个类似常量都定义在 netinet/in.h 中：

假设我们要写一个基于 TCP/IP 的 daytime 协议服务器。回忆一下，它使用端口 13。我们的 sockaddr_in 结构将如下所示：

图 9. 示例服务器 sockaddr_in

7.5.1.3.2. listen

继续我们之前的电话比喻：当你告诉总机你在哪个分机接电话后，你就走进办公室，确保电话插好了，铃声打开了。此外，你还要确保电话支持“通话中等待”，以便即使你正在通话中也能听到新的来电。

这里的 backlog 参数告诉 sockets：在你还在处理上一个请求时，最多可以接受多少个挂起的请求。换句话说，它决定了待处理连接队列的最大长度。

7.5.1.3.3. accept

电话铃响之后，你接起电话，就建立了与客户端的连接。该连接会一直保持，直到你或客户端挂断为止。

注意这次 addrlen 是一个指针。这是因为在这个调用中由 socket 来填写 addr，也就是 sockaddr_in 结构。

返回值是一个整数。实际上，accept 返回的是一个 新 socket。你将使用这个新 socket 来与客户端通信。

那旧的 socket 呢？它仍然监听更多的请求（还记得我们传给 listen 的 backlog 吗？），直到我们调用 close。

而新的 socket 仅用于通信。它是完全连接的，不能再传给 listen 去接受其他连接。

7.5.1.3.4. 我们的第一个服务器

我们的第一个服务器比我们的第一个客户端要复杂一些：不仅使用了更多的 sockets 函数，而且我们需要将它写成一个守护进程（daemon）。

最好的方式是，在绑定端口之后创建一个 子进程。主进程随即退出，将控制权还给 shell（或调用它的其他程序）。

子进程调用 listen，然后进入一个无限循环，接受连接、提供服务、最终关闭该连接的 socket。

我们首先创建一个 socket。然后填写 sa 中的 sockaddr_in 结构体。注意对 INADDR_ANY 的条件使用：

其值为 0。由于我们刚刚对整个结构体使用了 bzero，再次将其设为 0 是多余的。但如果我们将代码移植到某个 INADDR_ANY 也许不是零的系统上，就必须显式地将它赋值给 sa.sin_addr.s_addr。多数现代 C 编译器足够聪明，它们会发现 INADDR_ANY 是一个常量，只要它的值是零，就会自动优化掉整个条件语句。

成功调用 bind 之后，我们就准备好变成一个 守护进程（daemon）：我们使用 fork 创建一个子进程。在父进程和子进程中，变量 s 都是我们的 socket。父进程不再需要它，于是它调用 close，然后返回 0，告知其父进程它已经成功终止。

与此同时，子进程继续在后台运行。它调用 listen，将 backlog 设置为 4。这个值不需要太大，因为 daytime 并不是一个有很多客户端频繁请求的协议，而且每个请求也能被瞬间处理完毕。

最后，守护进程启动一个无限循环，按以下步骤操作：

1. 调用 accept。它会阻塞，直到有客户端连接。此时，它会获得一个新的 socket c，用于与这个特定客户端通信。

2. 使用 C 函数 fdopen 将 socket 从底层 文件描述符 转换为 C 风格的 FILE 指针，这样可以后续使用 fprintf。

3. 获取当前时间，并用 ISO 8601 格式打印到 client “文件”中。随后使用 fclose 关闭该文件，这也会自动关闭对应的 socket。

我们可以将这个模式 泛化，作为许多其他服务器的模板：

图 10. 顺序服务器（Sequential Server）

这个流程图适用于 顺序服务器，即一次只能服务一个客户端的服务器，就像我们的 daytime 服务器一样。只有在客户端和服务器之间没有真正的“对话”时，这种方式才是可行的：一旦服务器检测到客户端连接，它便立即发送一些数据，然后关闭连接。整个过程可能只需几纳秒便完成。

这种流程图的优点在于，除了 fork 之后父进程退出之前那一瞬间，始终只有一个 进程 活跃：服务器不会占用太多内存和系统资源。

注意，我们在流程图中添加了 初始化守护进程 的步骤。虽然我们的例子中不需要初始化守护进程，但这是在程序流程中设置 signal 信号处理器、打开可能用到的文件等的良好位置。

几乎流程图中所有内容都可以原样用于许多不同的服务器中，唯独 serve 部分是个例外。我们可以把它当作一个 “黑箱”，即根据自己的服务器需求特别设计的部分，然后“插入”到其余部分中即可。

并非所有协议都如此简单。很多协议都需要从客户端接收请求、回复请求，然后再次接收同一客户端的新请求。因此，它们无法预先知道需要服务多长时间。这类服务器通常会为每个客户端创建一个新进程。在新进程服务其客户端的同时，守护进程仍可继续监听新的连接。

现在，请将上述源代码保存为 daytimed.c（按照惯例，守护进程的程序名以字母 d 结尾）。编译后尝试运行它：

发生了什么？如你所知，daytime 协议使用的是端口 13。但所有小于 1024 的端口都是保留给超级用户的（否则任何人都可以伪装成一个守护进程，服务一个常见端口，从而造成安全漏洞）。

这次以超级用户身份再试一次：

什么…… 没有任何输出？我们再试一次：

每个端口在同一时间只能被一个程序绑定。我们的第一次尝试实际上是成功的：它启动了子守护进程并静默返回。它仍在后台运行，并将一直运行，直到你终止它、它的系统调用失败，或者你重启系统。

很好，我们知道它在后台运行。但它真的 工作 吗？怎么知道它是一个正确的 daytime 服务器？很简单：

telnet 先尝试使用新的 IPv6，失败后改用 IPv4 并成功连接。守护进程正常运行。

如果你能通过 telnet 访问另一台 UNIX® 系统，也可以用它来远程测试服务器。我所用的计算机没有静态 IP 地址，因此我做了如下测试：

它确实工作了。那么用域名也行吗？

顺便说一句，telnet 在我们的守护进程关闭 socket 后打印 Connection closed by foreign host 消息，这证明我们代码中使用 fclose(client); 的做法确实起到了作用。

7.6. 辅助函数

FreeBSD 的 C 标准库包含许多用于 socket 编程的辅助函数。例如，在我们的示例客户端中，我们是将 time.nist.gov 的 IP 地址硬编码进程序的。但我们并不总是知道 IP 地址。即使知道，如果程序允许用户输入 IP 地址，甚至是域名，它也会更灵活。

7.6.1. gethostbyname

这两个函数都会返回一个指向 hostent 结构体的指针，该结构体中包含大量关于该域名的信息。对我们的用途来说，该结构体中的 h_addr_list[0] 字段指向正确地址的 h_length 字节，这些字节已经是 网络字节序。

这使得我们可以创建一个更加灵活——也更加实用——的 daytime 程序版本：

现在我们可以在命令行中输入域名（或 IP 地址，二者皆可），程序就会尝试连接该地址的 daytime 服务器。否则，它仍然会默认连接 time.nist.gov。不过即便是这种情况，我们也使用了 gethostbyname，而不是硬编码 192.43.244.18。这样一来，即使它将来更换了 IP 地址，我们依然可以找到它。

由于从本地服务器获取时间几乎不花什么时间，你可以连续运行两次 daytime：第一次从 time.nist.gov 获取时间，第二次从你自己的系统中获取。然后你就可以比较两者的结果，看看你的系统时钟有多精确：

如你所见，我的系统时间比 NIST 时间快了两秒。

7.6.2. getservbyname

servent 结构体包含 s_port 字段，其中保存了正确的端口号，且已经是 网络字节序。

如果我们事先不知道 daytime 服务使用的端口，可以这样获取：

通常你是知道端口号的。但如果你正在开发一个新的协议，可能会在一个非官方端口上测试它。某一天，你会为该协议和它的端口注册编号（哪怕只是写进你的 /etc/services 文件中，getservbyname 正是查这个文件）。在上述代码中你也可以不返回错误，而是临时指定一个端口号。一旦你将协议列入 /etc/services，你的软件就能自动找到对应端口，而无需重写代码。

7.7. 并发服务器

与顺序服务器不同，并发服务器 必须能够同时为多个客户端提供服务。例如，一个 聊天服务器 可能会为某个特定客户端服务几个小时——它不能等这个客户端断开了，才去服务下一个客户端。

这就要求我们对流程图进行重大改动：

图 11. 并发服务器

我们将 服务逻辑 从 守护进程 中移到了独立的 服务进程 中。但由于每个子进程会继承所有已打开的文件（socket 被视为一种文件），新进程不仅会继承由 accept 返回的 连接句柄，也会继承由顶层进程最初创建的 监听 socket。

但 服务进程 并不需要这个监听 socket，因此应立即对它执行 close 操作。同样地，守护进程 也不再需要连接 socket，不仅应当关闭它，而且 必须 关闭——否则迟早会耗尽可用的 文件描述符。

当 服务进程 完成服务后，它应关闭连接 socket。此时不再返回 accept，而是直接退出。

在 UNIX® 中，进程实际上并不会真正 退出，而是会 返回 给它的父进程。通常父进程会调用 wait 来等待其子进程，并获取其返回值。但我们的 守护进程 不能就此停止并等待子进程完成。否则就违背了创建多个子进程的初衷。但如果它永远不调用 wait，子进程就会变成 *僵尸进程（zombie）*——虽然不再起作用，但仍残留在系统中。

因此，守护进程 需要在 初始化阶段 设置 信号处理器。至少要处理 SIGCHLD 信号，以便清除子进程的返回值，并释放它们占用的系统资源。

这也正是为什么流程图中多了一个不连接任何其他模块的 处理信号 方框。顺便说一句，许多服务器还会处理 SIGHUP 信号，并通常将其解释为超级用户发出的“重新读取配置文件”的信号。这样我们就可以更改设置，而不必杀掉并重启这些服务器。

4.1. 编写符合 I18N 标准的程序

为了让您的程序对其他语言用户更加实用，我们希望您能够按照 I18N 标准进行编程。GNU 的 gcc 编译器和像 QT、GTK 这样的图形界面库通过对字符串的特殊处理来支持 I18N。编写符合 I18N 的程序非常简单，这也使得其他人可以迅速将您的程序移植到其他语言。请参考特定库的 I18N 文档以获取更多细节。

与普遍认知相反，编写符合 I18N 的代码其实很容易。通常这只是将您的字符串包装在特定库的函数中。此外，请确保支持宽字符或多字节字符。

4.1.1. 统一 I18N 努力的呼声

我们注意到，各个国家的 I18N/L10N 工作经常在重复彼此的劳动。我们中很多人一次又一次地在低效地重复造轮子。我们希望 I18N 领域的主要群体能聚集起来，形成类似 Core Team 所负责的那种统一协作。

当前，我们希望您在编写或移植 I18N 程序时，能将其发送到每个国家相关的 FreeBSD 邮件列表中进行测试。未来，我们希望创建出无需任何脏补丁即可在所有语言中工作的应用程序。

4.1.2. Perl 与 Python

Perl 和 Python 拥有 I18N 和宽字符处理库。请在进行 I18N 编程时使用它们。

4.2. 使用 POSIX.1 本地语言支持（NLS）实现消息本地化

在支持各种输入编码和国家惯例（如不同的小数点符号）这些基础 I18N 功能之上，更高级的 I18N 还可以对程序输出的消息进行本地化。一种常见的做法是使用 POSIX.1 NLS 函数，这些函数作为 FreeBSD 基本系统的一部分提供。

4.2.1. 将本地化消息组织成目录文件

POSIX.1 NLS 基于目录文件（catalog file），这些文件使用所需编码格式包含本地化的消息。消息被组织成若干集合，每条消息在其所属集合中通过一个整数编号标识。目录文件的命名惯例是使用包含的语言环境名，加上 .msg 扩展名。例如，ISO8859-2 编码的匈牙利语消息应该存储在名为 hu_HU.ISO8859-2 的文件中。

这些目录文件是普通文本文件，包含带编号的消息。可以通过在行首添加 $ 符号写注释。集合边界也通过特殊注释分隔，其中 set 关键字必须紧跟在 $ 符号之后，然后是集合编号。例如：

4.2.2. 在源代码中使用目录文件

第二个参数是一个常量，有两个取值：

• NL_CAT_LOCALE，表示目录文件基于 LC_MESSAGES。

• 0，表示使用 LANG 环境变量查找目录文件。

4.2.3. 一个实际示例

以下示例展示了如何以灵活方式使用 NLS 目录。

首先，将以下代码行放入程序的公共头文件中，并在所有需要本地化消息的源文件中包含该头文件：

接着，将以下代码放入主源文件的全局声明部分：

最后是打开、读取和关闭目录文件的实际代码片段：

4.2.3.1. 减少需要本地化的字符串数量

有一个很好的方法可以减少需要本地化的字符串数量，就是使用 libc 的错误信息。这也有助于避免重复，并为许多程序可能遇到的常见错误提供一致的错误信息。

首先，下面是一个没有使用 libc 错误信息的例子：

这个例子可以改写为通过读取 errno 并据此打印错误信息来输出错误：

在这个例子中，自定义字符串被省略了，因此翻译人员在本地化程序时的工作量会更少，用户在遇到这个错误时将看到熟悉的 “Not a directory” 错误信息。这条信息对他们来说可能更为熟悉。请注意，为了直接访问 errno，必须包含 errno.h。

值得注意的是，有些情况下 errno 会由前面的调用自动设置，因此不需要显式设置：

4.2.4. 使用 bsd.nls.mk

使用目录文件需要一些重复的步骤，例如编译目录文件并将其安装到正确的位置。为了进一步简化这一过程，bsd.nls.mk 引入了一些宏。无需显式包含 bsd.nls.mk，它会由常见的 Makefile（例如 bsd.prog.mk 或 bsd.lib.mk）自动包含进来。

回归测试用于针对系统中的特定部分进行测试，以确认其按预期运行，并确保旧的错误不会被重新引入。

FreeBSD 的回归测试工具可以在 FreeBSD 源码树中的 src/tools/regression 目录下找到。

6.1. 微基准测试检查清单

本节包含在 FreeBSD 上或对 FreeBSD 本身进行正确微基准测试的建议。

并非每次测试都能用到以下所有建议，但使用得越多，基准测试检测微小差异的能力就越强。

• 禁用 APM 以及任何其他形式的时钟干预（ACPI？）。

• 最小化磁盘 I/O，若可行则完全避免。

• 不要挂载不需要的文件系统。

• 如果可能，将 /、/usr 以及其他文件系统挂载为只读。这可以避免因访问时间（atime）更新而引起的磁盘 I/O 干扰。

• 在每次测试迭代之间重启系统，以保证状态一致。

• 从内核中移除所有非必要的设备驱动程序。例如，如果测试中不需要 USB，就不要在内核中加入 USB。驱动程序往往有计时器在运行。

• 如果不是测试网络，测试前不要配置网络，或者测试结束后再将结果发出。

• 禁用“Turbo 模式”，因为它会根据环境调整时钟频率。这意味着即使代码完全相同，基准测试结果也可能因时间、饮品甚至办公室里其他人的存在而不同。

如果系统必须连接公共网络，要注意广播流量的突发峰值。虽然几乎察觉不到，但它仍然会占用 CPU 周期。多播（Multicast）也存在类似问题。

• 将每个文件系统放在单独的磁盘上，减少因磁头寻道优化带来的抖动。

• 尽量减少串口或 VGA 控制台的输出。将输出写入文件可减少抖动。（串口控制台容易成为瓶颈。）测试过程中不要触碰键盘，哪怕是空格或退格键也会影响结果。

• 保证测试时间足够长，但不要太长。若测试太短，时间戳精度不足；若太长，温度变化和晶体频率漂移会影响结果。经验法则：不少于 1 分钟，不超过 1 小时。

• 每个测试至少运行 3 次，最好是“修改前”和“修改后”都运行超过 20 次。如有可能，交叉运行（例如：不要先运行 20 次“前”，再运行 20 次“后”），这样有助于识别环境因素。不要按 1:1 交替运行，而是 3:3，有助于发现交互效应。

推荐模式为：bababa{bbbaaa}*。 这样，前 1+1 次就能初步判断趋势（若完全跑偏可及时终止测试），3+3 次可以估算标准差（决定是否值得长时间运行），后续数据可用于趋势和交互分析。

• 如果基准测试表现异常差，检查是否有异常的中断源导致的中断量暴增。有报告指出部分 ACPI 版本存在“异常行为”，会产生过多中断。为诊断异常测试结果，可以用 vmstat -i 拍几张快照，看看有没有异常。

• 注意内核和用户空间的优化参数，以及调试选项。很容易不小心遗漏某项，最后发现测试内容不一致。

6.2. FreeBSD 源码 Tinderbox

Tinderbox 包括以下部分：

• 一个构建脚本 tinderbox，自动签出指定版本的 FreeBSD 源码树并构建。

• 一个监督脚本 tbmaster，监视各个 Tinderbox 实例、记录输出，并发送失败通知邮件。

• 一个名为 index.cgi 的 CGI 脚本，用于读取 tbmaster 日志并以 HTML 格式生成简洁易读的摘要。

• 一组持续构建 FreeBSD 各主要代码分支最新状态的构建服务器。

• 一个网页服务器，用于保存完整的 Tinderbox 日志，并显示最新摘要信息。

关于 tinderbox 和 tbmaster 脚本的更多信息，请参见它们的手册页：tinderbox(1) 和 tbmaster(1)。

6.3. index.cgi 脚本

脚本从 main() 开始，首先验证是否在官方 Tinderbox 网站上运行。如果不是，则会显示一页提示，并给出官方网站的链接。

接着，它扫描日志目录，获取存在日志文件的配置项、分支和架构清单，避免在脚本中硬编码这些列表，造成空行或空列。该信息由日志文件名提取，文件名需匹配以下格式：

官方 Tinderbox 构建服务器使用的配置名称与其构建的分支一致。例如，releng_8 配置用于构建 RELENG_8 以及所有仍受支持的 8.x 发布分支。

完成启动过程后，会为每个配置调用 do_config()。

do_config() 会为单个 Tinderbox 配置生成 HTML 内容。

它先生成表头行，然后遍历指定配置下的每个分支构建，每个分支输出一行，流程如下：

• 对每个项目：

  • 对该架构下的每台机器：

    • 若存在简略日志文件：

      • 调用 success() 判断构建是否成功。

      • 输出修改大小。

      • 输出简略日志文件大小并附带链接。

      • 如果存在完整日志文件：

        • 输出完整日志文件大小并附带链接。

    • 否则：

      • 不输出内容。

上述 success() 函数会扫描简略日志文件中是否含有 “tinderbox run completed” 字样，以判断构建是否成功。

配置和分支按其“分支等级”排序，排序规则如下：

• HEAD 和 CURRENT 的等级为 9999。

• RELENG_x 的等级为 *xx*99。

• RELENG_x_y 的等级为 xxyy。

这意味着 HEAD 总是最高等级，RELENG 分支按数字升序排列，每个 STABLE 分支高于其派生的 release 分支。例如，FreeBSD 8 中的顺序为：

• RELENG_8（等级 899）

• RELENG_8_3（等级 803）

• RELENG_8_2（等级 802）

• RELENG_8_1（等级 801）

• RELENG_8_0（等级 800）

Tinderbox 用 CSS 定义表格中每个单元格的颜色。构建成功显示绿色文字，构建失败显示红色文字。颜色会随时间推移逐渐变灰，每过半小时颜色就更趋向灰色。

6.4. 官方构建服务器

目前有三个构建服务器：

freebsd-current.sentex.ca 构建：

• HEAD，适用于 amd64、arm、i386、i386/pc98、ia64、mips、powerpc、powerpc64 和 sparc64。

• RELENG_9 以及受支持的 9.X 分支，适用于 amd64、arm、i386、i386/pc98、ia64、mips、powerpc、powerpc64 和 sparc64。

freebsd-stable.sentex.ca 构建：

• RELENG_8 以及受支持的 8.X 分支，适用于 amd64、i386、i386/pc98、ia64、mips、powerpc 和 sparc64。

freebsd-legacy.sentex.ca 构建：

• RELENG_7 以及受支持的 7.X 分支，适用于 amd64、i386、i386/pc98、ia64、powerpc 和 sparc64。

6.5. 官方摘要站点

• Apache 被设置为使用 index.cgi 作为 DirectoryIndex。

3.1. 概要

本章描述了一些困扰 UNIX® 程序员数十年的安全问题，以及一些帮助程序员避免编写可被利用代码的新工具。

3.2. 安全设计方法论

编写安全的应用程序需要一种极其谨慎和悲观的世界观。应用程序应遵循“最小权限”原则运行，使得任何进程运行时都不拥有超过其完成功能所需的最小访问权限。应尽可能重用之前经过测试的代码，以避免他人已经修复过的常见错误。

UNIX® 环境的一个陷阱是，很容易对环境的健全性做出假设。应用程序绝不应信任用户输入（无论以何种形式）、系统资源、进程间通信或事件的时序。UNIX® 进程不是同步执行的，因此逻辑操作很少是原子的。

3.3. 缓冲区溢出

缓冲区溢出从冯·诺依曼架构诞生之初便已存在。它们在 1988 年因 Morris Internet 蠕虫而首次广泛引起关注。不幸的是，这种基本攻击方式至今仍然有效。迄今为止，最常见的缓冲区溢出攻击类型是基于破坏栈的攻击。

大多数现代计算机系统使用栈来向过程传递参数并存储局部变量。栈是一种先进后出（LIFO）的缓冲区，位于进程映像的高地址内存区域。当程序调用一个函数时，会创建一个新的“栈帧”。这个栈帧由传递给函数的参数以及一块动态大小的局部变量空间组成。“栈指针”是一个寄存器，保存当前栈顶的位置。由于这个值在新数据不断压入栈顶时不断变化，许多实现还提供一个“帧指针”，它位于栈帧的开头附近，以便更容易以它为基准寻址局部变量。函数调用的返回地址也存储在栈上，这正是栈溢出攻击的根源 —— 因为函数中局部变量的溢出可以覆盖该函数的返回地址，可能允许恶意用户执行任意代码。

虽然基于栈的攻击最为常见，但也有可能通过堆（malloc/free）实现栈的溢出。

C 编程语言不像许多其他语言那样对数组或指针执行自动边界检查。此外，标准 C 库中充斥着一些非常危险的函数：

3.3.1. 缓冲区溢出示例

我们来看看，如果向这个小程序输入 160 个空格再按回车，这个进程的内存映像会是什么样子。

显然，可以设计出更具恶意的输入来执行实际的已编译指令（例如执行 exec(/bin/sh)）。

3.3.2. 避免缓冲区溢出

解决栈溢出问题最直接的办法是始终使用带有长度限制的内存和字符串复制函数。strncpy 和 strncat 是标准 C 库的一部分。这些函数接受一个长度参数，该参数应不大于目标缓冲区的大小。这些函数会从源复制最多 “length” 个字节到目标中。但这些函数存在多个问题。若输入数据的长度与目标缓冲区相等，它们都不保证以 NUL 结尾。此外，这两个函数在长度参数上的语义不一致，程序员很容易混淆使用方法。若将短字符串复制到一个大缓冲区，与 strcpy 相比，这些函数的性能也大打折扣，因为 strncpy 会用 NUL 填满指定大小。

为了解决这些问题，出现了另一组内存复制实现：strlcpy 和 strlcat。这些函数在传入非零长度参数时，始终保证目标字符串以 null 结尾。

3.3.2.1. 基于编译器的运行时边界检查

不幸的是，目前仍有大量代码在不使用任何边界限制复制函数的情况下盲目地进行内存拷贝。幸运的是，存在一种方式可以帮助防止此类攻击 —— 编译器实现的运行时边界检查。

ProPolice 通过在调用函数之前在栈的关键区域放置伪随机数来防止基于栈的缓冲区溢出及其他攻击。当函数返回时，这些“金丝雀值”会被检查，如果发现已被更改，程序会立即中止。因此，任何试图修改返回地址或栈上其他变量以执行恶意代码的行为都极不可能成功，因为攻击者还必须设法保持这些伪随机金丝雀值不被破坏。

使用 ProPolice 重新编译应用程序是防止大多数缓冲区溢出攻击的有效手段，尽管仍有被绕过的可能。

3.3.2.2. 基于库的运行时边界检查

对于无法重新编译的二进制软件，编译器机制完全无效。在这种情况下，有一些库对 C 库中的不安全函数（如 strcpy、fscanf、getwd 等）进行了重新实现，并确保这些函数绝不会写越过栈指针。

• libsafe

• libverify

• libparanoia

不幸的是，这些基于库的防护措施存在一些缺陷。这些库仅能防御极少数与安全相关的问题，并未修复实际根本问题。如果应用程序使用了 -fomit-frame-pointer 编译选项，这些防护可能会失效。此外，用户可以覆盖或取消设置 LD_PRELOAD 和 LD_LIBRARY_PATH 环境变量，从而绕过这些防护。

3.4. SetUID 问题

每个进程至少关联有 6 个不同的 ID，因此必须非常谨慎地控制进程在任意时刻所拥有的访问权限。尤其是，所有调用 seteuid 的应用程序应在权限不再需要时立即放弃这些权限。

真实用户 ID 只能由超级用户进程更改。用户初次登录时由登录程序设置此 ID，之后很少再改变。

有效用户 ID 是在程序具有 setuid 位时由 exec() 函数设置的。应用程序可以随时调用 seteuid()，将有效用户 ID 设置为真实用户 ID 或保存的 set-user-ID。当 exec() 函数设置有效用户 ID 时，先前的值会保存在保存的 set-user-ID 中。

3.5. 限制程序运行环境

限制进程的传统方法是使用 chroot() 系统调用。此调用会改变进程及其所有子进程所引用路径的根目录。要使该调用成功，进程必须对所引用目录具有执行（搜索）权限。新环境实际上要等到调用 chdir() 进入新目录后才会生效。还应注意，如果进程拥有 root 权限，是可以轻易逃出 chroot 环境的。例如可以通过创建设备节点读取内核内存，或将调试器附加到 chroot 环境之外的进程，或用其他多种创造性方式实现逃脱。

可以通过 sysctl 变量 kern.chroot_allow_open_directories 对 chroot() 系统调用的行为进行一定控制。当此值设置为 0 时，如果有任何目录是打开的，chroot() 将以 EPERM 失败。若设置为默认值 1，则在进程已经处于 chroot() 环境下且存在任何打开的目录时，chroot() 将以 EPERM 失败。若设置为其他值，则完全跳过对打开目录的检查。

3.5.1. FreeBSD 的 jail 功能

Jail 的概念在 chroot() 的基础上扩展，通过限制超级用户的权限来创建一个真正的“虚拟服务器”。一旦设置了 jail，所有网络通信都必须通过指定的 IP 地址进行，而该 jail 中的“root 权限”被大大限制。

在 jail 中，任何在内核中使用 suser() 调用进行的超级用户权限测试都会失败。不过，一些对 suser() 的调用已经被替换成了新的接口 suser_xxx()。这个函数负责识别或拒绝 jail 中进程对超级用户权限的访问。

处于 jail 环境中的超级用户进程仍然拥有以下权限：

• 使用 setuid、seteuid、setgid、setegid、setgroups、setreuid、setregid、setlogin 操作凭据；

• 使用 setrlimit 设置资源限制；

• 修改某些 sysctl 节点（如 kern.hostname）；

• 执行 chroot()；

• 设置 vnode 的标志位：chflags、fchflags；

• 设置 vnode 的属性，如文件权限、所有者、组、大小、访问时间和修改时间；

• 在 Internet 域中绑定特权端口（端口号小于 1024）。

Jail 是一个非常有用的工具，可以在安全的环境中运行应用程序，但它也有一些不足。目前，IPC 机制尚未转换为 suser_xxx 接口，因此某些应用（如 MySQL）无法在 jail 中运行。虽然 jail 中的超级用户权限被大大限制，但目前还无法精确地定义“限制到什么程度”。

3.5.2. POSIX®·1e 进程能力

POSIX® 已发布一份工作草案，添加了事件审计、访问控制列表、细粒度权限、信息标记和强制访问控制等内容。

3.6. 信任

应用程序永远不应该假设用户环境中的任何内容是可靠的。这包括（但不限于）：用户输入、信号、环境变量、资源、IPC、内存映射、文件系统工作目录、文件描述符、打开的文件数量等。

你永远不应假设可以捕获用户可能提供的所有非法输入。相反，应用程序应当使用正向过滤，仅允许你认为安全的特定输入子集。数据验证不当已经成为许多漏洞的根源，尤其是在面向万维网的 CGI 脚本中。对于文件名，应当格外注意路径（如 "../"、"/"）、符号链接和 shell 转义字符。

Perl 有一个非常强大的特性叫做 “Taint 模式”，可以防止脚本在不安全的方式下使用来自程序外部的数据。该模式会检查命令行参数、环境变量、本地化信息、某些系统调用的返回值（如 readdir()、readlink()、getpwxxx()）以及所有文件输入。

3.7. 竞争条件

竞争条件是一种由于对事件相对时序的意外依赖而导致的异常行为。换句话说，程序员错误地假设某个事件总是会在另一个事件之前发生。

竞争条件的一些常见原因包括信号、访问检查和文件打开操作。信号本质上是异步事件，因此在处理它们时必须特别小心。使用 access(2) 进行权限检查后再调用 open(2) 显然不是原子操作。用户可能会在两次调用之间移动文件。因此，有特权的应用程序应该先调用 seteuid()，然后直接使用 open()。同理，应用程序在调用 open() 前应始终设置合适的 umask，从而避免不必要的 chmod() 调用。

[1] Dave A Patterson and John L Hennessy. Copyright® 1998 Morgan Kaufmann Publishers, Inc. 1-55860-428-6. Morgan Kaufmann Publishers, Inc. Computer Organization and Design. The Hardware / Software Interface. 1-2.

[2] W. Richard Stevens. Copyright® 1993 Addison Wesley Longman, Inc. 0-201-56317-7. Addison Wesley Longman, Inc. Advanced Programming in the Unix Environment. 1-2.

[3] Marshall Kirk McKusick and George Neville-Neil. Copyright® 2004 Addison-Wesley. 0-201-70245-2. Addison-Wesley. The Design and Implementation of the FreeBSD Operating System. 1-2.

[4] Aleph One. Phrack 49; "Smashing the Stack for Fun and Profit".

[5] Chrispin Cowan, Calton Pu, and Dave Maier. StackGuard; Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks.

[6] Todd Miller and Theo de Raadt. strlcpy and strlcat — consistent, safe string copy and concatenation.

作为内核开发人员，了解内核构建过程是必要的。调试 FreeBSD 内核时，必须能够构建一个内核。已知有两种构建内核的方法：

注意

9.1. 更快但脆弱的构建方法

这种方法在进行内核代码开发时可能会更有用，并且在仅调整内核配置文件中的一个或两个选项时，实际可能比文档中描述的过程更快。另一方面，它可能会导致内核构建出现意外的中断。

1. 复制

   # /usr/sbin/config MYKERNEL

2. 复制

   # cd ../compile/MYKERNEL

3. 编译内核：

   复制

   # make depend
   # make

4. 安装新内核：

   复制

   # make install

10.1. 获取内核崩溃转储

一旦内核发生 panic，系统重启是不可避免的。一旦系统重启，系统物理内存（RAM）的内容将丢失，以及在崩溃前交换设备上的任何数据。为了保存物理内存中的数据，内核使用交换设备作为在崩溃后重启时存储 RAM 中数据的临时位置。这样，在 FreeBSD 崩溃后重新启动时，可以提取内核映像并进行调试。

注意

已配置为转储设备的交换设备仍然充当交换设备。当前不支持将转储写入非交换设备（例如磁带或 CDRW）。 “交换设备”等同于“交换分区”。

有几种类型的内核崩溃转储可供选择：

• 完整内存转储：包含物理内存的完整内容。

• 小型转储：仅包含内核使用的内存页（FreeBSD 6.2 及更高版本）。

• 文本转储：包含捕获的脚本或交互式调试器输出（FreeBSD 7.1 及更高版本）。

自 FreeBSD 7.0 起，小型转储是默认的转储类型，在大多数情况下，它会捕获完整内存转储中所有必要的信息，因为大多数问题只需要使用内核状态来进行隔离。

10.1.1. 配置转储设备

技巧

重要

在内核崩溃之前，确保在 rc.conf(5) 中指定的 dumpdir 已经存在！

复制

# mkdir /var/crash
# chmod 700 /var/crash

另外，请记住，/var/crash 目录的内容是敏感的，极有可能包含诸如密码等机密信息。

10.1.2. 提取内核转储

技巧

如果你正在测试一个新的内核，但需要启动不同的内核才能使系统恢复正常，使用引导提示符中的 -s 标志将其仅引导到单用户模式，然后执行以下步骤：

复制

# fsck -p
# mount -a -t ufs       # 确保 /var/crash 可写
# savecore /var/crash /dev/ad0s1b
# exit                  # 退出到多用户模式

10.1.3. 测试内核转储配置

# shutdown now
...
Enter full pathname of shell or RETURN for /bin/sh:
# mount -a -u -r
# sysctl debug.kdb.panic=1
debug.kdb.panic: panic: kdb_sysctl_panic
...

10.2. 使用 kgdb 调试内核崩溃转储

注意

要进入调试器并开始从转储中获取信息，启动 kgdb：

# kgdb -n N

其中 N 是要检查的 vmcore.N 后缀。要打开最近的转储，可以使用：

# kgdb -n last

# kgdb /boot/kernel/kernel /var/crash/vmcore.0

你可以像调试其他程序一样，使用内核源代码调试崩溃转储。

此转储来自 5.2-BETA 内核，崩溃发生在内核的深处。下面的输出已修改，左侧包含行号。此第一个跟踪检查指令指针并获得回溯。第 41 行用于 list 命令的地址是指令指针，可以在第 17 行找到。如果你无法自己调试问题，大多数开发人员会要求至少将这些信息发送给他们。如果你能够解决问题，确保通过问题报告、邮件列表或提交代码的方式将你的补丁合并到源代码树中！

 1:# cd /usr/obj/usr/src/sys/KERNCONF
 2:# kgdb kernel.debug /var/crash/vmcore.0
 3:GNU gdb 5.2.1 (FreeBSD)
 4:Copyright 2002 Free Software Foundation, Inc.
 5:GDB is free software, covered by the GNU General Public License, and you are
 6:welcome to change it and/or distribute copies of it under certain conditions.
 7:Type "show copying" to see the conditions.
 8:There is absolutely no warranty for GDB.  Type "show warranty" for details.
 9:This GDB was configured as "i386-undermydesk-freebsd"...
10:panic: page fault
11:panic messages:
12:---
13:Fatal trap 12: page fault while in kernel mode
14:cpuid = 0; apic id = 00
15:fault virtual address   = 0x300
16:fault code:             = supervisor read, page not present
17:instruction pointer     = 0x8:0xc0713860
18:stack pointer           = 0x10:0xdc1d0b70
19:frame pointer           = 0x10:0xdc1d0b7c
20:code segment            = base 0x0, limit 0xfffff, type 0x1b
21:                        = DPL 0, pres 1, def32 1, gran 1
22:processor eflags        = resume, IOPL = 0
23:current process         = 14394 (uname)
24:trap number             = 12
25:panic: page fault
26      cpuid = 0;
27:Stack backtrace:
28
29:syncing disks, buffers remaining... 2199 2199 panic: mi_switch: switch in a critical section
30:cpuid = 0;
31:Uptime: 2h43m19s
32:Dumping 255 MB
33: 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
34:---
35:Reading symbols from /boot/kernel/snd_maestro3.ko...done.
36:Loaded symbols for /boot/kernel/snd_maestro3.ko
37:Reading symbols from /boot/kernel/snd_pcm.ko...done.
38:Loaded symbols for /boot/kernel/snd_pcm.ko
39:#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
40:240             dumping++;
41:(kgdb) list *0xc0713860
42:0xc0713860 is in lapic_ipi_wait (/usr/src/sys/i386/i386/local_apic.c:663).
43:658                     incr = 0;
44:659                     delay = 1;
45:660             } else
46:661                     incr = 1;
47:662             for (x = 0; x < delay; x += incr) {
48:663                     if ((lapic->icr_lo & APIC_DELSTAT_MASK) == APIC_DELSTAT_IDLE)
49:664                             return (1);
50:665                     ia32_pause();
51:666             }
52:667             return (0);
53:(kgdb) backtrace
54:#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
55:#1  0xc055fd9b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
56:#2  0xc056019d in panic () at /usr/src/sys/kern/kern_shutdown.c:550
57:#3  0xc0567ef5 in mi_switch () at /usr/src/sys/kern/kern_synch.c:470
58:#4  0xc055fa87 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:312
59:#5  0xc056019d in panic () at /usr/src/sys/kern/kern_shutdown.c:550
60:#6  0xc0720c66 in trap_fatal (frame=0xdc1d0b30, eva=0)
61:    at /usr/src/sys/i386/i386/trap.c:821
62:#7  0xc07202b3 in trap (frame=
63:      {tf_fs = -1065484264, tf_es = -1065484272, tf_ds = -1065484272, tf_edi = 1, tf_esi = 0, tf_ebp = -602076292, tf_isp = -602076324, tf_ebx = 0, tf_edx = 0, tf_ecx = 1000000, tf_eax = 243, tf_trapno = 12, tf_err = 0, tf_eip = -1066321824, tf_cs = 8, tf_eflags = 65671, tf_esp = 243, tf_ss = 0})
64:    at /usr/src/sys/i386/i386/trap.c:250
65:#8  0xc070c9f8 in calltrap () at {standard input}:94
66:#9  0xc07139f3 in lapic_ipi_vectored (vector=0, dest=0)
67:    at /usr/src/sys/i386/i386/local_apic.c:733
68:#10 0xc0718b23 in ipi_selected (cpus=1, ipi=1)
69:    at /usr/src/sys/i386/i386/mp_machdep.c:1115
70:#11 0xc057473e in kseq_notify (ke=0xcc05e360, cpu=0)
71:    at /usr/src/sys/kern/sched_ule.c:520
72:#12 0xc0575cad in sched_add (td=0xcbcf5c80)
73:    at /usr/src/sys/kern/sched_ule.c:1366
74:#13 0xc05666c6 in setrunqueue (td=0xcc05e360)
75:    at /usr/src/sys/kern/kern_switch.c:422
76:#14 0xc05752f4 in sched_wakeup (td=0xcbcf5c80)
77:    at /usr/src/sys/kern/sched_ule.c:999
78:#15 0xc056816c in setrunnable (td=0xcbcf5c80)
79:    at /usr/src/sys/kern/kern_synch.c:570
80:#16 0xc0567d53 in wakeup (ident=0xcbcf5c80)
81:    at /usr/src/sys/kern/kern_synch.c:411
82:#17 0xc05490a8 in exit1 (td=0xcbcf5b40, rv=0)
83:    at /usr/src/sys/kern/kern_exit.c:509
84:#18 0xc0548011 in sys_exit () at /usr/src/sys/kern/kern_exit.c:102
85:#19 0xc0720fd0 in syscall (frame=
86:      {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1, tf_ebp = -1077940712, tf_isp = -602075788, tf_ebx = 672411944, tf_edx = 10, tf_ecx = 672411600, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 671899563, tf_cs = 31, tf_eflags = 642, tf_esp = -1077940740, tf_ss = 47})
87:    at /usr/src/sys/i386/i386/trap.c:1010
88:#20 0xc070ca4d in Xint0x80_syscall () at {standard input}:136
89:---Can't read userspace from dump, or kernel process---
90:(kgdb) quit

技巧

如果你的系统经常崩溃并且磁盘空间不足，删除 /var/crash 中的旧 vmcore 文件可以节省相当多的磁盘空间！

10.3. 使用 DDB 进行在线内核调试

虽然 kgdb 作为离线调试器提供了非常高级的用户界面，但它有一些无法完成的任务。最重要的两个是设置断点和单步执行内核代码。

如果你需要对内核进行低级调试，可以使用一个在线调试器 DDB。它允许设置断点、单步执行内核函数、检查和修改内核变量等。然而，它无法访问内核源文件，且只能访问全局和静态符号，而不像 kgdb 那样拥有完整的调试信息。

要配置内核以包含 DDB，请在配置文件中添加以下选项：

options KDB

options DDB

待 DDB 内核启动运行，你可以通过多种方式进入 DDB。首先，最早的方式是使用启动标志 -d。这样，内核将在调试模式下启动，并在任何设备探测之前进入 DDB。因此，你甚至可以调试设备探测/附加函数。要使用此方法，请退出加载器的启动菜单并在加载器提示符下输入 boot -d。

第二种方式是在系统启动后进入调试器。有两种简单的方法可以实现这一点。如果你希望从命令提示符进入调试器，只需键入以下命令：

# sysctl debug.kdb.enter=1

或者，如果你在系统控制台上，可以使用键盘上的热键。默认的断点调试器快捷键是 Ctrl+Alt+ESC。对于 syscons，可以重新映射此快捷键，且一些分发的映射已经这样做，所以确保你知道正确的快捷键序列。如果你使用串行控制台，则可以通过串行线路上的 BREAK 信号进入 DDB（在内核配置文件中使用 options BREAK_TO_DEBUGGER）。这不是默认设置，因为很多串行适配器会无故生成 BREAK 信号，例如拔掉电缆时。

第三种方式是任何 panic 条件都会跳转到 DDB，如果内核已配置为使用它。因此，为无人值守的机器配置带有 DDB 的内核并不明智。

为了获得无人值守功能，可以在内核配置文件中添加：

options KDB_UNATTENDED

然后重新构建/重新安装内核。

DDB 的命令大致类似于一些 gdb 命令。你可能首先需要做的是设置断点：

break function-name address

数字默认为十六进制，但为了与符号名称区分开来，十六进制数字中以字母 a-f 开头的需要前面加 0x（其他数字则不需要）。简单的表达式也可以，例如：function-name + 0x103。

要退出调试器并继续执行，输入：

continue

要获取当前线程的堆栈跟踪，使用：

trace

要获取任意线程的堆栈跟踪，可以将进程 ID 或线程 ID 作为第二个参数传递给 trace。

如果要删除一个断点，使用：

del
 del address-expression

第一个形式会在断点命中后立即接受并删除当前断点。第二个形式可以删除任何断点，但需要指定确切的地址；可以通过以下命令获取该地址：

show b

或：

show break

要单步执行内核，可以尝试：

s

这会进入函数，但你可以让 DDB 跟踪这些函数，直到匹配的返回语句被达到，使用：

n

注意

这与 gdb 的 next 语句不同；它类似于 gdb 的 finish。多次按下 n 将导致继续执行。

要检查内存中的数据，可以使用（例如）：

x/wx 0xf0133fe0,40
 x/hd db_symtab_space
 x/bc termbuf,10
 x/s stringbuf

用于字/半字/字节访问，以及十六进制/十进制/字符/字符串显示。逗号后的数字是对象的数量。要显示接下来的 0x10 项，只需使用：

x ,10

类似地，使用

x/ia foofunc,10

来反汇编 foofunc 的前 0x10 条指令，并显示它们及其相对于 foofunc 开始位置的偏移。

要修改内存，使用写入命令：

w/b termbuf 0xa 0xb 0
 w/w 0xf0010030 0 0

命令修饰符（b/h/w）指定要写入的数据大小，第一个跟随的表达式是写入地址，剩下的被解释为写入到连续内存位置的数据。

如果需要查看当前的寄存器，可以使用：

show reg

或者，你可以通过例如以下命令显示单个寄存器的值：

p $eax

并通过以下命令修改它：

set $eax new-value

如果需要从 DDB 调用一些内核函数，只需输入：

call func(arg1, arg2, ...)

返回值将被打印出来。

ps

现在，你已经检查了内核崩溃的原因，想要重启系统。记住，根据先前故障的严重程度，并非所有内核部分仍然按预期工作。执行以下操作之一来关闭并重启系统：

panic

call boot(0)

可能是一个干净地关闭系统、sync() 所有磁盘并在某些情况下重启的好方法。只要内核的磁盘和文件系统接口没有损坏，这可能是一个几乎干净的关闭方式。

reset

这是灾难的最后逃生方式，几乎等同于按下大红按钮。

如果需要简短的命令总结，只需输入：

help

10.4. 在线内核调试使用远程 GDB

GDB 长期以来一直支持 远程调试。这通过一个非常简单的协议沿着串行线进行。与上述其他调试方法不同，使用远程 GDB 需要两台机器。一台是提供调试环境的主机，包括所有源代码和带有所有符号的内核二进制文件。另一台是运行相同内核副本的目标机器（可以选择剥离调试信息）。

为了使用远程 GDB，请确保在内核配置中包含以下选项：

makeoptions     DEBUG=-g
options         KDB
options         GDB

请注意，GDB 选项在 -STABLE 和 -RELEASE 分支的 GENERIC 内核中默认关闭，但在 -CURRENT 中已启用。

目标机器必须进入 GDB 后端，可以是由于 panic 或者通过故意触发进入调试器。在执行此操作之前，选择 GDB 调试后端：

# sysctl debug.kdb.current=gdb
debug.kdb.current: ddb -> gdb

注意

然后，强制进入调试器：

# sysctl debug.kdb.enter=1
debug.kdb.enter: 0KDB: enter: sysctl debug.kdb.enter

目标机器现在等待来自远程 GDB 客户端的连接。在调试机器上，进入目标内核的编译目录，并启动 gdb：

# cd /usr/obj/usr/src/amd64.amd64/sys/GENERIC/
# kgdb kernel
GNU gdb (GDB) 10.2 [GDB v10.2 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
...
Reading symbols from kernel...
Reading symbols from /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel.debug...
(kgdb)

通过以下命令初始化远程调试会话（假设使用的是第一个串口）：

(kgdb) target remote /dev/cuau0

现在，主机 GDB 将控制目标内核：

Remote debugging using /dev/cuau0
kdb_enter (why=<optimized out>, msg=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:506
506                     kdb_why = KDB_WHY_UNSET;
(kgdb)

技巧

您可以像使用任何其他 GDB 会话一样使用此会话，包括完全访问源代码，在 Emacs 窗口中以 gud-mode 运行它（这会在另一个 Emacs 窗口中自动显示源代码）等。

10.5. 调试控制台驱动程序

由于需要一个控制台驱动程序才能运行 DDB，如果控制台驱动程序本身出现故障，事情会变得更加复杂。您可能还记得使用串行控制台（通过修改启动块，或在 Boot: 提示符下指定 -h），并将标准终端连接到您的第一个串行端口。DDB 在任何配置了的控制台驱动程序上都能工作，包括串行控制台。

10.6. 调试死锁

如果可能，考虑进行进一步调查。如果您怀疑死锁发生在 VFS 层，下面的步骤尤其有用。请将这些选项添加到内核配置文件中。

makeoptions 	DEBUG=-g
options 	INVARIANTS
options 	INVARIANT_SUPPORT
options 	WITNESS
options 	WITNESS_SKIPSPIN
options 	DEBUG_LOCKS
options 	DEBUG_VFS_LOCKS
options 	DIAGNOSTIC

当死锁发生时，除了 ps 命令的输出外，还应提供来自 show pcpu、show allpcpu、show locks、show alllocks、show lockedvnods 和 alltrace 的信息。

为了获得线程进程的有意义的回溯，可以使用 thread thread-id 切换到线程栈，然后使用 where 进行回溯。

10.7. 使用 Dcons 进行内核调试

10.7.1. 通过 FireWire® 使用 Dcons

FireWire® 设备不限于集成在主板中的设备。桌面电脑可以使用 PCI 卡，笔记本电脑可以购买卡总线接口。

10.7.1.1. 在目标机器上启用 FireWire® 和 Dcons 支持

要在目标机器的内核中启用 FireWire® 和 Dcons 支持：

• 确保您的内核支持 dcons、dcons_crom 和 firewire。Dcons 应该与内核静态链接。对于 dcons_crom 和 firewire，模块应该是可以的。

• 确保启用了物理 DMA。您可能需要在 /boot/loader.conf 中添加 hw.firewire.phydma_enable=1。

• 添加调试选项。

• 如果使用 GDB 通过 FireWire® 调试，请在 /boot/loader.conf 中添加 dcons_gdb=1。

• 在 /etc/ttys 中启用 dcons。

• 可选地，要强制将 dcons 设置为高级控制台，请在 loader.conf 中添加 hw.firewire.dcons_crom.force_console=1。

# cd /sys/boot/i386 && make clean && make && make install

以下是一些配置示例。一个示例内核配置文件应该包含：

device dcons
device dcons_crom
options KDB
options DDB
options GDB
options ALT_BREAK_TO_DEBUGGER

示例 /boot/loader.conf 文件应包含：

dcons_crom_load="YES"
dcons_gdb=1
boot_multicons="YES"
hw.firewire.phydma_enable=1
hw.firewire.dcons_crom.force_console=1

10.7.1.2. 在主机机器上启用 FireWire® 和 Dcons 支持

要在主机机器的内核中启用 FireWire® 支持：

# kldload firewire

# dconschat -e \# -br -G 12345 -t 00-11-22-33-44-55-66-77

kgdb -r :12345 kernel

10.7.1.3. 一些常规提示

以下是一些常规提示：

为了充分利用 FireWire® 的速度，禁用其他较慢的控制台驱动程序：

# conscontrol delete ttyd0	     # 串口控制台
# conscontrol delete consolectl	# 视频/键盘

(setq gud-gdba-command-name "kgdb -a -a -a -r :12345")
(setq gdb-many-windows t)
(xterm-mouse-mode 1)
M-x gdba

对于 DDD (devel/ddd)，您可以使用以下命令：

# 远程串行协议
LANG=C ddd --debugger kgdb -r :12345 kernel
# 实时核心调试
LANG=C ddd --debugger kgdb kernel /dev/fwmem0.2

10.7.2. 与 KVM 一起使用 Dcons

10.7.2.1. 使用 Dcons 与 KVM

# dconschat -1

# dconschat -1 -M vmcore.XX

可以通过以下方式进行实时核心调试：

# fwcontrol -m target_eui64
# kgdb kernel /dev/fwmem0.2

10.8. 内核调试选项词汇表

本节提供了用于调试的编译时内核选项的简要词汇表：

• options KDB：编译内核调试器框架。options DDB 和 options GDB 需要此选项。几乎没有性能开销。默认情况下，当系统发生 panic 时，调试器会被触发，而不是自动重启。

• options KDB_UNATTENDED：将 debug.debugger_on_panic sysctl 的默认值更改为 0，该 sysctl 控制系统在 panic 时是否进入调试器。如果内核中未编译 options KDB，则默认行为是在 panic 时自动重启；如果编译了 options KDB，默认行为是在没有编译 options KDB_UNATTENDED 的情况下进入调试器。如果希望将内核调试器保留在内核中，但希望系统在不进行诊断时能够恢复，除非您能使用调试器，使用此选项。

• options KDB_TRACE：将 debug.trace_on_panic sysctl 的默认值更改为 1，该 sysctl 控制是否在 panic 时自动打印堆栈跟踪。尤其是在运行 options KDB_UNATTENDED 时，这对于在串行或 FireWire 控制台上收集基本调试信息非常有帮助，同时仍然能进行重启恢复。

• options DDB：编译支持控制台调试器 DDB。此交互式调试器可以在系统的任何活动低级控制台上运行，包括视频控制台、串行控制台或 FireWire 控制台。它提供基本的集成调试功能，如堆栈跟踪、进程和线程列表、锁状态转储、虚拟内存状态、文件系统状态和内核内存管理。DDB 不需要在第二台机器上运行软件，也不需要生成核心转储或完整的调试内核符号，提供实时的内核诊断。许多错误可以仅通过 DDB 输出完全诊断。此选项依赖于 options KDB。

• options GDB：编译支持远程调试器 GDB，可以通过串行电缆或 FireWire 进行操作。当调试器被触发时，可以附加 GDB 来检查结构内容、生成堆栈跟踪等。某些内核状态比在 DDB 中更难访问，因为 DDB 可以自动生成有用的内核状态摘要，如自动遍历锁调试或内核内存管理结构，而 GDB 需要在第二台机器上运行。另一方面，GDB 结合了内核源代码和完整的调试符号，并且能够了解完整的数据结构定义、局部变量，且可以编写脚本。此选项不要求在内核核心转储上运行 GDB。此选项依赖于 options KDB。

• options BREAK_TO_DEBUGGER，options ALT_BREAK_TO_DEBUGGER：允许在控制台上使用中断信号或替代信号进入调试器。如果系统在没有 panic 的情况下挂起，这是进入调试器的一种有用方法。由于当前内核锁定的原因，通过串行控制台生成的中断信号在进入调试器时更为可靠，因此通常推荐使用这种方式。此选项对性能的影响很小或没有影响。

• options INVARIANTS：将大量运行时断言检查和测试编译到内核中，这些检查和测试不断验证内核数据结构的完整性和内核算法的不变性。由于这些测试可能会比较耗费资源，因此默认情况下不编译，但它们有助于提供有用的“故障停止”行为，在内核数据损坏发生之前，某些类别的非预期行为会先进入调试器，使其更容易调试。这些测试包括内存擦洗和使用后释放的测试，这是影响性能的一个重要因素。此选项依赖于 options INVARIANT_SUPPORT。

• options INVARIANT_SUPPORT：options INVARIANTS 中的许多测试需要修改的数据结构或需要定义额外的内核符号。

• options WITNESS_SKIPSPIN：禁用 WITNESS 的自旋锁顺序检查。由于调度器中最常频繁地获取自旋锁，并且调度事件频繁发生，此选项可以显著加快运行 WITNESS 的系统。此选项依赖于 options WITNESS。

• options WITNESS_KDB：将 debug.witness.kdb sysctl 的默认值更改为 1，这会使 WITNESS 在检测到锁定顺序违规时进入调试器，而不仅仅是打印警告。此选项依赖于 options WITNESS。

• options SOCKBUF_DEBUG：对套接字缓冲区执行广泛的运行时一致性检查，这对于调试套接字错误和协议以及与套接字交互的设备驱动中的竞争条件非常有用。此选项对网络性能有显著影响，可能会改变设备驱动中的时序。

• options DEBUG_VFS_LOCKS：跟踪 lockmgr/vnode 锁的锁定获取点，扩展 DDB 中 show lockedvnods 显示的内容。此选项对性能有可测量的影响。

• options DIAGNOSTIC：启用附加的、较为昂贵的诊断测试，类似于 options INVARIANTS。

A.1. 概述

在 UNIX® 下进行汇编语言编程的文献资料非常有限。通常认为没有人会使用汇编语言，因为各种 UNIX® 系统运行在不同的微处理器上，所以一切应该使用 C 语言编写以保证可移植性。

实际上，C 语言的可移植性实际上是个神话。无论它们运行在哪种处理器上，即使是 C 程序在从一款 UNIX® 移植到另一款 UNIX® 时，也需要修改。通常，这样的程序充满了依赖于其编译系统的条件语句。

即使我们相信所有 UNIX® 软件都应该使用 C 或其他高级语言编写，我们仍然需要汇编语言程序员：谁来编写访问内核的 C 库部分呢？

在本章中，我将尝试向您展示如何使用汇编语言编写 UNIX® 程序，特别是在 FreeBSD 下。

版权® 2000-2001 G. Adam Stanislav。保留所有权利。

A.2. 工具

A.2.1. 汇编器

进行汇编语言编程最重要的工具是汇编器，它是将汇编语言代码转换为机器语言的软件。

本章使用 nasm 语法，因为大多数从其他操作系统转到 FreeBSD 的汇编语言程序员会觉得这种语法更易理解。而且，坦率地说，这也是我习惯的语法。

A.2.2. 链接器

汇编器的输出文件与任何编译器的输出文件一样，需要通过链接器来生成可执行文件。

FreeBSD 提供了标准的 ld(1) 链接器。它可以与任何汇编器生成的代码一起使用。

A.3. 系统调用

A.3.1. 默认调用约定

默认情况下，FreeBSD 内核使用 C 调用约定。此外，虽然内核是通过 int 80h 进行访问的，但程序会调用一个发出 int 80h 的函数，而不是直接发出 int 80h。

这种约定非常方便，并且比 MS-DOS® 使用的 Microsoft® 调用约定更为优越。为什么？因为 UNIX® 约定允许任何用任何语言编写的程序访问内核。

汇编语言程序也可以这样做。例如，我们可以打开一个文件：

kernel:
	int	80h	; 调用内核
	ret

open:
	push	dword mode
	push	dword flags
	push	dword path
	mov	eax, 5
	call	kernel
	add	esp, byte 12
	ret

这是非常简洁和可移植的编码方式。如果您需要将代码移植到使用不同中断或不同传递参数方式的 UNIX® 系统，只需要修改内核程序即可。

但汇编语言程序员通常喜欢优化性能。上面的例子需要 call/ret 组合。我们可以通过 push 一个额外的 dword 来消除它：

open:
	push	dword mode
	push	dword flags
	push	dword path
	mov	eax, 5
	push	eax		; 或任何其他 dword
	int	80h
	add	esp, byte 16

我们将 5 放入 EAX 寄存器中，以标识内核函数，此处为 open。

A.3.2. 替代调用约定

FreeBSD 是一款非常灵活的系统。它提供了其他访问内核的方式。然而，系统必须安装 Linux 模拟才能正常工作。

Linux 是一款类 UNIX® 系统。然而，它的内核使用与 MS-DOS® 相同的系统调用约定，即通过寄存器传递参数。与 UNIX® 约定类似，函数编号放在 EAX 中，参数则不通过堆栈传递，而是放在 EBX、ECX、EDX、ESI、EDI 和 EBP 中：

open:
	mov	eax, 5
	mov	ebx, path
	mov	ecx, flags
	mov	edx, mode
	int	80h

这种约定相对于 UNIX® 方式有一个很大的缺点，至少对汇编语言编程来说：每次进行内核调用时，您必须 push 寄存器，然后稍后再 pop 它们。这使得代码更庞大且运行较慢。尽管如此，FreeBSD 仍然提供了选择权。

如果您选择了 Linux 调用约定，您必须告诉系统。程序汇编并链接后，您需要为可执行文件打上品牌：

% brandelf -t Linux filename

A.3.3. 您应该使用哪种约定？

如果您专门为 FreeBSD 编程，您应该始终使用 UNIX® 约定：它更快，您可以将全局变量存储在寄存器中，不需要对可执行文件进行品牌化，也不需要在目标系统上安装 Linux 模拟包。

如果您希望创建可以在 Linux 上运行的可移植代码，您可能仍然希望为 FreeBSD 用户提供尽可能高效的代码。我将在解释基本内容之后，向您展示如何实现这一点。

A.3.4. 调用号

要告诉内核您正在调用哪个系统服务，请将其编号放入 EAX 中。当然，您需要知道这个编号是什么。

A.3.4.1. syscalls 文件

这些编号列在 syscalls 文件中。使用 locate syscalls 可以找到这个文件的多个不同格式，所有格式都从 syscalls.master 自动生成。

您可以在 /usr/src/sys/kern/syscalls.master 中找到默认 UNIX® 调用约定的主文件。如果您需要使用 Linux 模拟模式中实现的另一种约定，请阅读 /usr/src/sys/i386/linux/syscalls.master。

注意

不仅 FreeBSD 和 Linux 使用不同的调用约定，它们有时对相同的功能使用不同的编号。

syscalls.master 描述了如何进行调用：

0	STD	NOHIDE	{ int nosys(void); } syscall nosys_args int
1	STD	NOHIDE	{ void exit(int rval); } exit rexit_args void
2	STD	POSIX	{ int fork(void); }
3	STD	POSIX	{ ssize_t read(int fd, void *buf, size_t nbyte); }
4	STD	POSIX	{ ssize_t write(int fd, const void *buf, size_t nbyte); }
5	STD	POSIX	{ int open(char *path, int flags, int mode); }
6	STD	POSIX	{ int close(int fd); }
etc...

最左边的列告诉我们将哪个数字放入 EAX。

最右边的列告诉我们需要 push 什么参数。它们是从右到左依次 push 的。

例如，要 open 一个文件，我们需要首先 push mode，然后是 flags，最后是存储 path 地址的变量。

A.4. 返回值

如果系统调用没有返回某种类型的值，大多数情况下是没有用的：例如打开文件的文件描述符、读取到缓冲区的字节数、系统时间等。

此外，系统还需要告知我们是否发生了错误：例如文件不存在、系统资源耗尽、传递了无效参数等。

A.4.1. 手册页

在 UNIX® 系统下，传统的查看各种系统调用信息的地方是手册页。FreeBSD 在第 2 节中描述其系统调用，有时在第 3 节中。

如果成功，open() 返回一个非负整数，称为文件描述符。如果失败，返回 -1，并设置 errno 来指示错误。

对于刚接触 UNIX® 和 FreeBSD 的汇编语言程序员来说，立刻会产生一个令人困惑的问题：errno 到底在哪里，如何访问它？

注意

手册页中提供的信息适用于 C 程序。汇编语言程序员需要额外的信息。

A.4.2. 返回值在哪里？

不幸的是，这取决于……对于大多数系统调用，返回值在 EAX 中，但并非所有系统调用都如此。一个好的经验法则是，当首次处理一个系统调用时，先检查返回值是否在 EAX 中。如果不在那儿，您需要进一步的研究。

注意

我知道有一个系统调用将值返回在 EDX 中：SYS_fork。其他我处理过的系统调用都使用 EAX。但我还没有处理所有系统调用。

技巧

如果您在这里找不到答案或其他地方没有答案，可以研究 libc 源代码，看看它是如何与内核交互的。

A.4.3. errno 在哪里？

实际上，errno 根本不存在……

errno 是 C 语言的一部分，而不是 UNIX® 内核的一部分。当直接访问内核服务时，错误代码会返回到 EAX 中，这与通常存放返回值的寄存器相同。

这完全合理。如果没有错误，就没有错误代码。如果发生了错误，就没有返回值。一个寄存器可以同时存放这两者。

A.4.4. 如何判断是否发生了错误

在使用标准 FreeBSD 调用约定时，成功时 carry flag 会被清除，失败时会被设置。

在使用 Linux 模拟模式时，EAX 中的有符号值在成功时为非负值，并包含返回值。如果发生错误，值为负数，即 -errno。

A.5. 创建可移植代码

可移植性通常不是汇编语言的强项。然而，编写适用于不同平台的汇编语言程序是可能的，尤其是使用 nasm。我已经编写了可以在多个操作系统（如 Windows® 和 FreeBSD）上汇编的汇编语言库。

当您希望代码能够在两个不同平台上运行时，这尤其可行，这两个平台尽管有所不同，但基于类似的架构。

例如，FreeBSD 是 UNIX®，Linux 是 UNIX® 类似的操作系统。我只提到了它们之间的三个区别（从汇编语言程序员的角度看）：调用约定、函数号和返回值的方式。

A.5.1. 处理函数号

在许多情况下，函数号是相同的。然而，即使它们不相同，问题也很容易处理：不要在代码中直接使用数字，而是使用常量，根据目标架构不同进行定义：

%ifdef	LINUX
%define	SYS_execve	11
%else
%define	SYS_execve	59
%endif

A.5.2. 处理约定

调用约定和返回值（errno 问题）都可以通过宏来解决：

%ifdef	LINUX

%macro	system	0
	call	kernel
%endmacro

align 4
kernel:
	push	ebx
	push	ecx
	push	edx
	push	esi
	push	edi
	push	ebp

	mov	ebx, [esp+32]
	mov	ecx, [esp+36]
	mov	edx, [esp+40]
	mov	esi, [esp+44]
	mov	ebp, [esp+48]
	int	80h

	pop	ebp
	pop	edi
	pop	esi
	pop	edx
	pop	ecx
	pop	ebx

	or	eax, eax
	js	.errno
	clc
	ret

.errno:
	neg	eax
	stc
	ret

%else

%macro	system	0
	int	80h
%endmacro

%endif

A.5.3. 处理其他可移植性问题

上述解决方案可以处理大部分在 FreeBSD 和 Linux 之间编写可移植代码的情况。然而，对于某些内核服务，差异更为深入。

在这种情况下，您需要为那些特定的系统调用编写两个不同的处理程序，并使用条件汇编。幸运的是，您的大部分代码做的工作与调用内核无关，因此通常您只需要在代码中添加几个这样的条件部分。

A.5.4. 使用库

您可以通过编写一个系统调用库，完全避免主代码中的可移植性问题。为 FreeBSD 编写一个单独的库，为 Linux 编写另一个不同的库，甚至为更多操作系统编写其他库。

在您的库中，为每个系统调用编写一个单独的函数（或者，如果您喜欢传统的汇编语言术语，可以称之为过程）。使用 C 调用约定来传递参数，但仍然使用 EAX 来传递调用号。在这种情况下，您的 FreeBSD 库可以非常简单，因为许多看似不同的函数实际上只是指向相同代码的标签：

sys.open:
sys.close:
[等等...]
	int	80h
	ret

您的 Linux 库将需要更多不同的函数。但是即便如此，您也可以根据相同的参数数量来分组系统调用：

sys.exit:
sys.close:
[等等... 单参数函数]
	push	ebx
	mov	ebx, [esp+12]
	int	80h
	pop	ebx
	jmp	sys.return

...

sys.return:
	or	eax, eax
	js	sys.err
	clc
	ret

sys.err:
	neg	eax
	stc
	ret

最初，使用库的方法可能看起来不方便，因为它需要您生成一个代码依赖的单独文件。但它有许多优点：首先，您只需要编写一次，并且可以将其用于所有程序。您甚至可以让其他汇编语言程序员使用它，或者使用由他人编写的库。但或许库的最大优势是，您的代码可以通过简单编写一个新的库而无需更改代码，即可移植到其他系统，甚至其他程序员也能完成此操作。

如果您不喜欢使用库的想法，您至少可以将所有系统调用放在一个单独的汇编语言文件中，并将其与主程序链接。在这种情况下，移植者只需要创建一个新的目标文件来与主程序链接。

A.5.5. 使用包含文件

如果您将软件作为（或与）源代码一起发布，您可以使用宏并将它们放在一个单独的文件中，然后在代码中包含这个文件。

您的软件移植者只需编写一个新的包含文件。这样就不需要库或外部目标文件，但您的代码依然可以在无需编辑代码的情况下实现可移植性。

注意

这是我们将在本章中使用的方法。我们将把包含文件命名为 system.inc，并在处理新的系统调用时不断添加内容。

我们可以通过声明标准的文件描述符来开始我们的 system.inc：

%define	stdin	0
%define	stdout	1
%define	stderr	2

接下来，为每个系统调用创建一个符号名称：

%define	SYS_nosys	0
%define	SYS_exit	1
%define	SYS_fork	2
%define	SYS_read	3
%define	SYS_write	4
; [等等...]

我们添加一个短小、非全局的过程，命名为长名称，这样我们就不会在代码中不小心重复使用它：

section	.text
align 4
access.the.bsd.kernel:
	int	80h
	ret

然后，我们创建一个宏，它接收一个参数，即系统调用编号：

%macro	system	1
	mov	eax, %1
	call	access.the.bsd.kernel
%endmacro

最后，我们为每个系统调用创建宏，这些宏不接受任何参数。

%macro	sys.exit	0
	system	SYS_exit
%endmacro

%macro	sys.fork	0
	system	SYS_fork
%endmacro

%macro	sys.read	0
	system	SYS_read
%endmacro

%macro	sys.write	0
	system	SYS_write
%endmacro

; [等等...]