前言

glibc的测试套件的wiki主页为：https://sourceware.org/glibc/wiki/Testing/Testsuite

如何构建glibc？可以参考：glibc 知：构建和测试

测试套件目标

典型的测试用例在构建目录中写出一个扩展名为 .out 的文件，其中包含测试的输出。可以在测试用例失败的情况下检查此文件以确定问题所在。如果您在 bugzilla 中报告测试用例失败，请确保也包含相关 .out 文件的内容。

还有一个额外的测试目标：make xcheck。运行 make xcheck 包括 make check 的所有测试，但添加了一些额外的测试。这些额外的测试对可用于正常执行的执行环境有要求，例如网络连接，但不一定用于构建（作为构建系统的一部分）。

开发人员应该使用“make xcheck”而不是“make check”。在交叉编译设置中运行 Testsuite 时，make check 是必要的，因为它构建了 testroot 容器 [1]

运行“make check”或“make xcheck”时无需使用“-k”，失败的测试不会停止测试。如果 make 没有通过打印“测试结果摘要”来完成，那么说明测试过程中的某处存在问题。
在这里插入图片描述
[1] https://sourceware.org/pipermail/libc-alpha/2020-March/111815.html

只测试一项测试

要仅测试一个测试，您必须已经运行整个测试套件（为所有测试创建输出文件）。接下来，删除感兴趣的测试的单一*.out文件并重新运行测试。基础设施只会使用丢失的输出文件重新运行测试。

要加速此过程并将其限制为单个目录的测试，您必须使用-C <path to glibc source>/<top-level directory tests> 运行，例如：make -r PARALLELMFLAGS="-j4" -C /home /carlos/src/glibc/inet objdir=`pwd` check，只运行inet顶级目录的标准测试。

或者，您可以执行make subdirs=login -j8 check以并行运行login子目录中的所有测试。请注意，nptl目录中的-jN 会被自动忽略，因为其中一些测试使用多线程。
在这里插入图片描述

ABI检查

glibc 测试套件包含许多测试以检查 glibc 的 ABI 没有变更。它将生成的二进制文件中的符号名称和版本以及静态变量大小与源文件中 *.abilist 中维护的那些进行比较。测试作为“make check”的一部分运行。您也可以通过“make check-abi”单独运行它们。
在这里插入图片描述
为了提高 ABI 分析的质量，可以运行以下附加测试：

ABI compliance checker

有关 make xcheck 特定测试的详细信息

下面的列表描述了仅作为 make xcheck 的一部分的测试对执行环境的要求：

resolv/tst-leaks2 nss/bug-erange.c posix/bug-ga2.c
需要足够的网络连接才能在 www.gnu.org 上进行 DNS 查找
nptl/tst-setuid1.c 和 nptl/tst-setuid1-static.c
需要 /etc/passwd 中的用户“nobody”或类似的，以及作为当前用户 setuid 的能力。
nptl/tst-mutexpp1.c nptl/tst-mutexpp6.c nptl/tst-mutexpp10.c
需要足够的权限通过 pthread_mutexattr_setprioceiling 设置互斥优先级上限
sunrpc/tst-getmyaddr.c
至少需要在系统上配置一个非环回 IP 地址。
sunrpc/thrsvc.c
需要使用 IP 地址 127.0.0.1 的环回启动和运行
iconv/test-iconvconfig
需要在 $(inst_gconvdir) 下安装现有的 gconv-modules.cache

编写测试用例

使用测试驱动程序（在support/test-driver.c 中）启动您的测试用例。为此，您通常将测试用例编写为：

  /* This is your test case 'main' method.  */
  static int
  do_test (void)
  {
    /* Test goes here.  */
  }
  
  #include <support/test-driver.c>

在文件support/README-testing.c 中可以找到一个最小的完整示例。
测试用例中的诊断或信息性消息应打印到标准输出。这包括标记测试用例失败的消息。
如果你想在测试用例中打印一个不是失败的警告，那么也将它打印到标准输出。这可用于诸如在某个功能不可用时跳过测试之类的情况。我们不想打印到 stderr，因为它失去了 stdout 和 stderr 之间的顺序，在测试套件运行的输出中丢失，并且不是一个有用的区别。也就是说，stdout 和stderr 的区别不如PASS 和FAIL 的区别有用。
建议在诊断输出中使用info:、warning:和error:或FAIL前缀，以明确指示哪个输出反映了错误情况。
您可以包含<support/test-driver.h>并使用test_verbose变量来检查测试程序是否使用–verbose参数运行，以避免默认打印许多诊断消息。
如果打印错误消息，则需要确保指示失败。您可以通过调用exit (1)来执行此操作（在fork之后可能不起作用）。如果要继续执行，请从<support/check.h>调用support_record_failure()（它在fork后工作，因为它使用共享内存段，但在execve或动态共享对象后将不起作用）。不要使用abort或assert。
<support/test-driver.h> 中的EXIT_UNSUPPORTED是一个魔法退出状态（77），其指示该测试不支持此特定系统（可能是由于在运行时检测到的硬件或内核支持的缺乏）。
<support/test-driver.c> 中的测试驱动程序提供了一些用于自定义的钩子，例如自定义参数列表解析。有关详细信息，请参阅源文件中的文档。

使用交叉编译器进行测试

虽然在使用本机工具的系统上构建和测试 glibc 是进行 glibc 测试的最简单方法，但也可以构建包含 glibc 的交叉编译工具链并使用该工具链运行 glibc 测试套件。

要进行交叉编译测试，您需要使用 glibc 源代码中的 scripts/cross-test-ssh.sh 脚本，并在主机上的目录中进行构建，该目录在目标机器上也可见，具有相同的路径. 还需要能够使用 ssh 从主机访问目标机器。cross-test-ssh.sh 脚本中有关于此的详细信息。此脚本可用于运行“make check”、“make xcheck”或“make bench”。

由于主机和目标机器在 make 期间都在接触文件，因此一台机器上的更改需要立即在另一台机器上可见。由于缓存，这不是 NFS 的默认行为。您可能需要在 NFS 上使用“noac”选项才能使其工作。运行 make 时，此问题可能会导致类似以下消息：

touch: cannot touch ‘/home/sellcey/gcc/gcc_cross_testing/obj-mips-mti-linux-gnu/glibc/obj_default/localedata/de_DE.ISO-8859-1/LC_CTYPE’: No such file or directory

如果您通过构建 binutils、初始 GCC、glibc，然后重新构建 GCC（常见构建序列）来构建跨工具链，那么运行 glibc 测试套件可能会导致 glibc 在任何测试之前重新构建正在运行。这是因为 glibc 测试依赖于 glibc，而 glibc 依赖于 GCC（或至少一些 GCC 头文件）。如果您的第二个 GCC 构建覆盖了第一个，那么 make 将看到此更改并在进行任何测试之前重建 glibc 的许多部分（如果不是全部）。如果您知道要运行 glibc 测试套件，您可能希望在重建 GCC 之后和运行“make check”之前重建 glibc。您不能跳过第二个 GCC 构建，因为初始 GCC（如果使用 --without-headers 配置）将没有构建 glibc 测试程序所需的所有头文件和库。

已知的测试套件失败

abi-check

如果您使用–prefix配置选项为不同的前缀构建，您可能会看到由于_nl_default_dirname 的大小不同而导致检查失败。_nl_default_dirname的大小取决于前缀，/usr/share/locale被视为默认值，因此值为 0x12。如果您看到这样的差异，您应该检查大小是否与您的前缀相对应，即（前缀路径的长度 + 1）以确保您的更改没有真正破坏 abi。

bug-atexit3 和 nptl 测试

当为非标准前缀（即不是/usr）配置构建时，会再次看到这些失败。发生这种情况是因为构建的动态链接器无法找到libstdc++和libgcc_s.so，因为其默认搜索路径是构建目录，并回退到前缀目录中的ld.so.cache，即$prefix/etc/ld.so.cache。可以通过以下方式之一解决这些故障：