如何理解 GNU 源代码？

Question

如果这听起来有点愚蠢，我真的很抱歉。我刚刚读完《K&R》并做了一些练习。今年夏天，对于我的项目，我正在考虑重新实现一个 Linux 实用程序，以进一步扩展我对 C 的理解，因此我下载了 GNU tar 和 sed 的源代码，因为它们看起来都很有趣。然而，我很难理解它从哪里开始，主要实现在哪里，所有奇怪的宏来自哪里等等。

我有很多时间，所以这不是真正的问题。我是否应该首先熟悉 GNU 工具链（即 make、binutils、..）才能理解程序？或者也许我应该从一些较小的东西开始（如果有这样的事情）？

如果这很重要的话，我对 Java、C++ 和 python 有一点经验。

谢谢！

Answer 1

GNU 程序庞大而复杂。 GNU Hello World 的大小表明，即使是最简单的 GNU 项目也需要大量的代码和配置围绕它。

对于初学者来说，自动工具很难理解，但是您不需要理解它们就可以阅读代码。即使您修改了代码，大多数时候您也可以简单地运行 make 来编译您的更改。

要阅读代码，您需要一个好的编辑器（VIM、Emacs）或 IDE（Eclipse）以及一些用于浏览源代码的工具。 tar 项目包含一个 src 目录，这是一个很好的起点。程序总是以 main 函数开始，因此请执行

grep main *.c

或使用 IDE 来搜索该函数。它位于 tar.c 中。现在，跳过所有初始化内容，直到

/* Main command execution.  */

您看到子命令的开关。如果你传递 -x 它会执行此操作，如果你传递 -c 它会执行此操作，等等。这是这些命令的分支结构。如果你想知道这些宏是什么，运行

grep EXTRACT_SUBCOMMAND *.h

那里你可以看到它们列在 common.h 中。

在 EXTRACT_SUBCOMMAND 下面，你会看到一些有趣的东西：

read_and (extract_archive);

read_and() 的定义（再次使用 grep 获得）：

read_and (void (*do_something) (void))

单个参数是一个类似于回调的函数指针，因此 read_and 应该会读取一些内容，然后调用函数<代码>extract_archive。再次，对其进行 grep，您将看到以下内容：

  if (prepare_to_extract (current_stat_info.file_name, typeflag, &fun))
    {
      if (fun && (*fun) (current_stat_info.file_name, typeflag)
      && backup_option)
    undo_last_backup ();
    }
  else
    skip_member ();

请注意，真正的工作发生在调用 fun 时。 fun 又是一个函数指针，在prepare_to_extract 中设置。 fun 可能指向 extract_file，它负责实际的写入。

我希望我已经向您介绍了这一点，并向您展示了我如何浏览源代码。如果您有相关问题，请随时与我联系。

Answer 2

tar 和 sed 等程序的问题是双重的（当然，这只是我的观点！）。首先，他们都真的很老了。这意味着多年来有多个人维护它们，具有不同的编码风格和不同的个性。对于 GNU 实用程序来说，它通常相当不错，因为它们通常强制执行相当一致的编码风格，但这仍然是一个问题。另一个问题是它们的便携性令人难以置信。通常，“可移植性”被视为一件好事，但如果走向极端，这意味着您的代码库最终会充满一些小技巧和技巧，以解决特定硬件和系统中的模糊错误和极端情况。对于像 tar 和 sed 这样广泛移植的程序，这意味着需要考虑大量的极端情况和晦涩的硬件/编译器/操作系统帐户。

如果你想学习 C，那么我想说最好的起点不是尝试研究别人编写的代码。相反，尝试自己编写代码。如果您确实想从现有的代码库开始，请选择一个正在积极维护的代码库，您可以在其中看到其他人所做的更改他们所做的，请按照邮件列表上的讨论进行操作，很快。

使用 tar 和 sed 等成熟的程序，您可以看到本来会发生的讨论的结果，但您看不到如何实时做出软件设计决策和更改。只有主动维护的软件才会发生这种情况。

当然这只是我的意见，如果你愿意的话，你可以持保留态度:)

Answer 3

为什么不下载 coreutils 的源代码 (http://ftp.gnu.org/gnu/coreutils/< /a>）并查看像 yes 这样的工具？不到 100 行 C 代码，是一个功能齐全、有用且真正基础的 GNU 软件。

Answer 4

GNU Hello 可能是最小、最简单的 GNU 程序，并且很容易理解。

Answer 5

我知道有时浏览 C 代码会很混乱，特别是如果您不熟悉它的话。我建议您使用工具来帮助您浏览函数、符号、宏等。然后查看对于 main() 函数。

当然，您需要熟悉这些工具，但不需要成为专家。

Answer 6

如果您还不知道的话，请了解如何使用 grep 并使用它来搜索 main 函数以及您感兴趣的其他所有内容。您可能还想使用代码浏览工具，例如 ctags 或 cscope 它也可以与 vim 和 emacs 集成，或者如果您更喜欢的话可以使用 IDE。

Answer 7

我建议使用 ctags 或 cscope 用于浏览。您可以将它们与 vim/emacs.它们在开源世界中被广泛使用。

它们应该位于每个主要 Linux 发行版的存储库中。

Answer 8

理解一些使用大量宏、实用函数等的代码可能很困难。为了更好地浏览随机C或C++软件的代码，我建议采用这种方法，这也是我通常使用的：

1. 安装Qt开发工具和Qt Creator

2. 下载您想要检查的源代码，并将它们设置为编译（对于 GNU 内容，通常只需 ./configure）。

3. 在源目录的根目录中运行qmake -project，为Qt Creator生成Qt .pro文件。

4. 在 Qt Creator 中打开 .pro 文件（当需要时，不要使用影子构建）。

5. 为了安全起见，在 Qt Creator 项目视图中，删除默认的构建步骤。 .pro 文件仅用于在 Qt Creator 中导航。

6. 可选：如果您想在 Qt Creator 下构建和运行/调试，请设置自定义构建和运行步骤。仅导航不需要。

7. 使用Qt Creator浏览代码。请特别注意按名称查找内容的定位器（kb 快捷键 Ctrl+K）、“跟随光标下的符号”（kb 快捷键 F2）和“查找用法”（kb 快捷键 Ctrl-Shift-U）。

Answer 9

我必须看一下“sed”才能看看问题出在哪里；它不应该那么大。我看了看，明白了问题所在，我感觉就像查尔顿·赫斯顿第一次看到海滩上一座破碎的雕像一样。我将要描述的“sed”的所有内容也可能适用于“tar”。但我还没有看过它。

很多 GNU 代码都被严重破坏了——到了无法维护的病态遗产的程度——出于我不知道的原因。我不知道它到底是什么时候发生的，也许是 1990 年代末或 2000 年代初，但就像有人按下了开关，突然间，所有漂亮的模块化、大部分独立的代码小部件都被各种无关紧要的纠缠物所大量破坏。与应用程序本身试图执行的操作没有任何联系。

在您的情况下，“sed”：整个库（不必要地）被拖入应用程序中。至少早在 4.2 版本（您的查询之前的最后一个版本）就是这种情况，可能在那之前 - 我必须检查一下。

另一件被破坏的事情是构建系统（再次）到了不可维护的地步。

所以，你在这里真正谈论的是遗产救援。

我的建议...对于任何已经存在很长时间的代码库来说都是通用的...就是尽可能深入地挖掘并首先回到其最早的形式；并扩展并查看其他“sed”——例如 UNIX 档案中的那些。

https://www.tuhs.org/Archive/

或在 BSD 存档中：

https://github.com/freebsd

https://github.com/weiss/original-bsd

（第二个在其早期提交中更深入地探讨了早期 BSD。）

许多“sed”都在GNU 页面（但不是全部）可以在“下载”下找到，作为 GNU sed 页面上的“镜像”链接：

https://www.gnu.org/software/sed/

1.18 版本仍然完好无损。版本 1.17 隐含完整，因为存在 1.17 到 1.18 的差异。这两个版本都没有将所有额外的东西堆在上面。它更能代表 GNU 软件在陷入所有纠缠之前的样子。

它实际上非常小 - *.c 和 *.h 文件总共只有 8863 行。从那开始。

对我来说，任何代码库的分析过程都会破坏原始代码，并且总是需要大量的重构和重新设计；简化来自于更好、更原生地编写它，同时保留或增加其功能。几乎总是，它是由只有几年经验的人写的（我的意思是：例如，不到 20 年），因此没有完全掌握母语流利程度，也没有广泛的背景知识。能够很好地编程。

为此，如果您这样做，强烈建议您已经准备好或添加了一些测试套件。例如，4.2 版软件中有一个，尽管它可能是对 1.18 和 4.2 之间添加的新功能进行压力测试。请注意这一点。 （因此，可能需要减少测试套件以适应 1.18。）您所做的每个更改都必须通过套件中的任何测试进行验证。

您需要拥有母语流利的语言……或者通过进行练习和其他类似的练习来获得它的意愿和能力。如果你没有足够的岁月，你就会碰壁。走得越深，前进就越困难。这说明你的经验还不够，宽度还不够。因此，这个练习将成为你学习经历的一部分，你只需要慢慢地完成即可。

由于第一个版本的日期很早，无论如何您都必须进行一些重写，只是为了使其达到标准。更高版本可以用作此过程的指南。至少，它应该达到 C99，因为这实际上是 POSIX 的一部分。换句话说，你至少应该跟上本世纪的步伐！

仅仅让它发挥作用的挑战就足够了。只要这样做，你就会学到很多东西。让它投入运行的过程就是建立一个“基线”。一旦你这样做了，你就有了自己的版本，你可以从“分析”开始。

一旦建立了基线，您就可以通过重构和重新设计全力推进。测试套件有助于防止失误和插入错误。您应该将（重新）制作的所有版本保留在本地存储库中，以便您可以跳回到较早的版本，以防您需要跟踪突然出现的测试失败或其他错误。您可能会发现，有些错误从一开始就根深蒂固（因此：发现隐藏的错误）。

当您（重新）编写了令您满意的基线后，您就可以继续在后续版本中进行分层。在 GNU 档案中，1.18 直接跳至 ​​2.05。您必须在两者之间进行“比较”，以查看所有更改都在哪里，然后将它们移植到 1.18 版本中以获得 2.05 版本。这将帮助您更好地了解所做更改解决的问题以及所做的更改。

在某些时候，你会遇到 GNU 的垃圾墙。在 GNU 的历史档案中，版本 2.05 直接跳至 ​​3.01。从 3.01 版本开始，一些纠缠开始出现。所以，我们这里有一堵软墙。但还有一个 3.01 的早期测试套件，您应该将其与 1.18 一起使用，而不是 4.2 的测试套件。

当你撞上垃圾墙时，你会直接看到纠缠是什么，你必须决定是继续顺风车还是把它们扔到一边。我无法告诉你哪个方向是兔子洞，除了 SED 很长一段时间以来都很好，其中大部分或全部是 POSIX 标准（甚至是当前的标准）中列出并强制执行的内容，以及什么是之前的版本 3 就服务于这个目的。

我运行了差异。在 2.05 和 3.01 之间，diff 文件有 5000 行。好的。这（大部分）很好，对于正在开发的代码来说是很自然的，但其中一些可能来自软垃圾墙。在 3.01 与 4.2 上运行 diff 会生成超过 60000 行的 diff 文件。您只需问自己：一个低于 10000 行的程序（遵守国际标准 (POSIX)）如何能够产生 60000 行差异？答案是：这就是我们所说的“膨胀”。因此，在 3.01 和 4.2 之间，您会看到一个代码库非常常见的问题：膨胀的增加。

所以，这几乎告诉你哪个方向（“顺其自然”与“把它扔到一边”）是兔子洞。我可能会坚持使用 3.01，并粗略地回顾一下 3.01 和 4.2 之间的差异以及更改日志，以大致了解更改内容，然后就这样保留它，除非可能会找到不同的方法写下他们认为有必要改变的内容，如果改变的理由是有效的话。

我以前做过遗产救援，当时“遗产”这个词还没有出现在大多数人的词汇中，我很快就认出了它的标志性标志。这是一个人可能会经历的过程。

我们已经在一些大型代码库中看到了这种情况。实际上，Wayland 取代 X11 是一次大规模的遗产救援活动。 clang 正在取代 GNU 的 gcc 也可能被认为是这种情况的一个例子。