Posts

使用自编译的C++标准库 不想使用系统自带的 C++ 库，需要自己编译一套 llvm 的 libc++.so 以及 STL 的时候，可以参考如下命令： 1 2 3 4 5 6 7 8 9 10 11 cmake -G Ninja\ -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lldb;lld"\ -DLLVM_ENABLE_RUNTIMES="libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;offload"\ -DLIBCXX_ENABLE_SHARED=ON\ -DLIBCXXABI_ENABLE_SHARED=ON\ -DLLVM_USE_LINKER=lld\ -DCMAKE_BUILD_TYPE=Release\ -DLLVM_BUILD_LLVM_DYLIB=ON\ -DLLVM_LINK_LLVM_DYLIB=ON\ -DCMAKE_INSTALL_PREFIX=/home/debian/tools/clang-llvm-21\ ../llvm-project/llvm 编译完库之后，使用显式参数告诉clang++使用自编译库： 1 clang++ -stdlib=libc++ test.cpp -o test 使用ripgrep查找libc++.so所在目录： 1 2 3 4 5 6 7 8 9 debian@debian:~/tools/clang-llvm-21$ rg --files | rg so | rg "libc++" share/libc++/v1/std/memory_resource.inc share/libc++/v1/std/source_location.inc lib/libclang.so.21.0.0git lib/aarch64-unknown-linux-gnu/libc++abi.so.1.0 lib/aarch64-unknown-linux-gnu/libc++.so lib/aarch64-unknown-linux-gnu/libc++.modules.json lib/aarch64-unknown-linux-gnu/libc++.so.1.0 lib/libclang-cpp.so.21.0git 使用ldd或者运行可执行文件test之前，需要先注入环境变量： ...

本文是 Juliet Test Suite v1.2 for C_Cpp - User Guide.pdf 的中文翻译，官方网站位于 https://samate.nist.gov/SARD/documentation#juliet 第一章：介绍 1.1 文件目的 本文档描述了为C/C++开发的Juliet测试套件v1.2。该测试套件由国家安全局（NSA）的安全软件中心（CAS）创建并开发，专门用于评估静态分析工具的能力。它适用于任何希望将测试用例用于自己的测试目的，或希望更深入了解测试用例创建方式的人员。 本文档解释了测试用例命名和设计背后的理念，并提供了如何使用命令行界面（CLI）编译和运行它们的指导。第8节还提供了如何评估工具结果的详细信息。 测试用例可公开下载于 http://samate.nist.gov/SRD/testsuite.php。 1.2 测试用例是什么？ 测试用例是可以构建的代码片段，用于研究静态分析工具。一个测试用例针对的正是一类缺陷，但其他不相关的缺陷可能偶然存在。例如，C测试用例“CWE476_NULL_Pointer_Dereference__char_01”只针对空指针解引用缺陷。除了包含目标缺陷的构造之外，每个测试用例通常还包含一个或多个执行与有缺陷构造类似功能的非缺陷构造。一小部分测试用例不包含非缺陷构造，被认为是“仅坏”测试用例（见第4.5节）。 1.3 为什么需要测试用例？ 为了研究静态分析工具，CAS需要软件进行工具分析。CAS之前考虑使用“自然”或“人造”软件。自然软件是没有为测试静态分析工具而创建的软件。开源软件应用程序，如Apache Web服务器httpd.apache.org和OpenSSH套件www.openssh.com，是自然软件的例子。人造软件，在这个情况下，是包含故意缺陷并专门为测试静态分析工具而创建的软件。测试用例是人造软件的一个例子。 1.3.1 自然代码的限制 在以前的研究工作中，CAS在测试静态分析工具时使用了自然和人造代码的组合。此外，CAS遵循了国家标准与技术研究院（NIST）静态分析工具博览会（SATE），该博览会检验了静态分析工具在自然代码上的性能。 从这些努力中获得的经验表明，使用自然代码通常面临特定的挑战，例如： 评估工具结果以确定其正确性 - 当静态分析工具在自然代码上运行时，每个结果都需要审查以确定代码是否真的在指定位置有指定类型的缺陷（即，结果是否正确或“假阳性”）。对于大多数自然代码的结果来说，这种审查并非易事，通常无法在合理的时间内以高度的确定性确定给定结果的正确性。 比较不同工具的结果 - 在自然代码上比较静态分析工具的结果很复杂，因为不同的工具以不同的方式报告结果。例如，许多缺陷涉及“源”的受污染数据和“汇”不当使用该数据的地方。一些工具可能报告源，而其他工具报告汇。有时，多个受污染数据的源都指向一个汇，这可能导致不同工具报告不同数量的结果。 识别代码中没有工具发现的缺陷 - 在评估静态分析工具时，需要一个“标准”列表，列出代码中的所有缺陷，以便识别每个工具未能报告的缺陷。对于自然代码来说，创建这个“标准”很困难，特别是在识别没有任何自动化工具报告的缺陷时，因此只能通过手动代码审查来发现。 评估工具在代码中未出现的构造上的性能 - 自然代码的限制在于，即使是不同项目的组合，也可能不包含CAS想要测试的所有有缺陷和无缺陷的构造。即使代码中出现的缺陷类型也可能因复杂的控制和数据流而被混淆，以至于自然代码中的缺陷即使被通常能捕获该类型缺陷的工具也会未被检测到。为了解决这个问题，CAS考虑使用“播种”方法将缺陷和非缺陷嵌入到自然代码中。最终，CAS决定创建测试用例，而不是使用“播种”，因为CAS认为使用“播种”代码研究静态分析工具将过于复杂，并且导致测试的构造少于预期。 基于这些经验和挑战，CAS决定开发人造测试用例来测试静态分析工具。使用人造代码通过允许CAS控制、识别和定位代码中包含的缺陷和非缺陷来简化工具研究。 1.3.2 测试用例的限制 尽管使用测试用例简化了静态分析工具研究，但它可能以以下两种方式限制结果的适用性： 测试用例比自然代码简单 - 一些测试用例故意是正在测试的缺陷的最简单形式。即使是包含控制或数据流复杂性的测试用例也比自然代码简单，无论是在代码行数还是在分支、循环和函数调用的数量和类型上。这种简单性可能会夸大结果，即工具可能报告在测试用例中它们很少在自然、非平凡代码中报告的缺陷。 测试用例中缺陷和无缺陷构造的频率可能不反映它们在自然代码中的频率 - 每个类型的缺陷在测试用例中测试一次，无论这种缺陷类型在自然代码中有多常见或罕见。因此，两个在测试用例上有相似结果的工具可能在自然代码上提供非常不同的结果，例如，如果一个工具发现常见缺陷，而另一个工具只发现罕见缺陷。即使在测试用例上表现不佳的工具也可能在自然代码上表现良好。同样，每个无缺陷构造在测试用例中也只出现一次，无论该构造在自然代码中有多常见。因此，测试用例上的假阳性率可能与工具在自然代码上的比率大不相同。 1.4 创建测试用例 大多数非类基缺陷的测试用例是使用包含缺陷的源文件和CAS创建的名为“测试用例模板引擎”的工具生成的。生成的测试用例文件包含在第一行的注释中，表明它们是生成的。 一些缺陷类型不能被CAS的自定义测试用例模板引擎生成。这些缺陷类型的测试用例是手动创建的。由于资源限制，这些测试用例被创建为只包含缺陷的最简单形式，没有添加控制或数据流复杂性。 第二章：测试用例范围 本节提供了测试用例范围的详细信息。通常，测试用例侧重于底层平台上可用的函数，而不是第三方库的使用。 尽管C和C++是不同的编程语言，但它们被视为一个单元，因为C++通常是C的超集。此外，大多数软件保证工具都支持C和C++。 尽可能地，C/C++测试用例将API调用限制在C标准库中，该库在所有平台上都可用。为了涵盖更多的问题，一些测试用例针对Windows平台（使用Windows特定的API函数）。未来，这项工作可以扩展到涵盖Windows之外的其他平台独有的API函数。不使用任何第三方C或C++库函数。 C测试用例代码针对C89标准，以便测试用例可以使用可能不支持C语言新版本的各种工具进行编译和分析。 测试用例限制了C++构造和特性的使用，仅在需要它们时使用（例如，与C++类或“new”操作符相关的测试用例）。除非针对的缺陷类型需要，否则测试用例不使用C++标准库。 2.1 测试用例选择 CAS在选择测试用例的缺陷类型时使用了几个来源： 软件保证团队在CAS中的经验 CAS之前工具研究中使用的缺陷类型 供应商关于其工具识别的缺陷类型的信息 MITRE通用弱点枚举（CWE）中的弱点信息 虽然每个测试用例都使用CWE标识符作为其名称的一部分，但创建测试用例并不需要特定于缺陷类型的CWE条目。为所有适当的缺陷类型创建测试用例，并使用最相关的CWE条目（可能相当通用和/或抽象）为每个测试用例命名。 2.2 测试用例统计 测试用例涵盖了2011年CWE/SANS前25个最危险软件错误中的11个。在测试用例未涵盖的14个CWE条目中，有10个是设计问题，不适合CAS测试用例的结构。其他四个不是特定于C/C++的，并且在相关的Java测试用例中得到涵盖。（见附录B，了解与前25个相关的测试用例的详细信息）。 ...

最近看了《Understanding the Linux® Virtual Memory Manager》里面的第十二章 SHARED MEMORY VIRTUAL FILESYSTEM ，对文件系统以及内存文件管理有了更加深入的了解，下面是看了这一章节之后对其中一些概念的理解以及拓展，要是想了解这一章，建议读原文，配合这篇博客辅助理解 Linux 哲学 在 Linux 里面，一切皆文件，所有的东西都可以看作一个文件，而凡是文件，都应该支持或者接近POSIX文件操作（比如 read() ，write() ，open()） 每一块内存对象，都可以被看作一个文件，一旦赋予这块内存对象相对应的文件描述，就可以使用像使用普通文件那样子操作内存对象 而这也正是 VFS（虚拟文件系统 virtual file system ，包括内存文件系统以及共享内存管理系统）的设计理念以及实现方向 VMA（virtual memory area） Linux 内核用vm_area_struct结构体描述某一段连续的虚拟内存区域 VMA（virtual memory area），每个虚拟内存区域 VMA 都有自己的vm_area_struct 结构体 内存描述符 mm_struct 指向进程的整个地址空间，vm_area_struct 只是指向了虚拟空间的一段，这块虚拟内存区域VMA的地址范围为 [vm_start, vm_end) ，左开右闭 vm_area_struct 是由双向链表链接起来的，它们是按照虚拟地址降序排序的，每个这样的结构都对应描述一个地址空间范围 为了快速根据地址找到对应的 VMA，内核对其建立了红黑树索引，红黑树的每个叶子结点就是一个VMA区域，引入红黑树的好处是可以提高查找VMA的效率（即便VMA的数量翻倍，VMA的查找次数也只增加一次） 之所以通过 VMA 分隔内存区域是因为每个虚拟区间可能来源不同，有的可能来自可执行映像，有的可能来自共享库，而有的可能是动态内存分配的内存区，所以对于每个由 vm_area_struct 结构所描述的区间的处理操作和它前后范围的处理操作不同，因此 linux 把虚拟内存分割管理，并利用了虚拟内存处理例程 vm_ops 来抽象对不同来源虚拟内存的处理方法 不同的虚拟区间其处理操作可能不同，linux 在这里利用了面向对象的思想，即把一个虚拟区间看成是一个对象，用 vm_area_struct 描述这个对象的属性，其中的 vm_operation 结构描述了在这个对象上的操作 虚拟内存空间管理概括图 ...

前几天服务器又宕机了，仔细排查原来是磁盘的占用满了，在这里记录一下使用到的命令以及相关小知识 在 linux shell 里面查看磁盘占用信息主要有两个命令，一个是 du ，另外一个是 df du : disk usage 主要用于递归计算指定文件夹的大小 它通过搜索文件来计算每个文件的大小然后累加，只能看到当前存在的，没有被删除的文件 使用 du - sh 可以显示当前目录的总磁盘使用量，并且以易读的格式（如 K、M、G）显示 -s 或 --summarize：只显示总计的磁盘使用量，而不是列出每个子目录的详细使用量，也就是说，它会显示当前目录（或指定目录）的总大小，而不是列出每个子目录的大小 -h 或 --human-readable：以更易读的格式显示磁盘使用量，例如以 K（千字节）、M（兆字节）、G（吉字节）等单位显示，而不是以字节为单位 1 2 hcy@debian:~$ du -sh 6.6G . 而 du -h 可以查看当前目录下所有文件和子目录的大小,这个会递归列出所有子目录占用信息，内容会非常多 有些情况下为了可以自顶向下逐层文件夹地分析哪些目录是导致磁盘臃肿的原因，可以使用 --max-depth 参数，下面是只递归展示一层（第一层）的占用情况（ –max-depth 1 ） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 root@xtz:~/build# du -h --max-depth 1 2.7M ./unittests 244K ./cmake 32K ./docs 124K ./share 13G ./bin 32K ./libexec 11M ./test 3.6G ./tools 4.1M ./include 1.5M ./examples 32K ./runtimes 13G ./lib 99M ./utils 150M ./projects 8.9M ./CMakeFiles 30G . 但是使用 du -h --max-depth 1 的结果并不是按照磁盘占用情况从小到大的顺序排序的，还是不够直观地分析占用情况，于是通过使用 sort -rh 进行进一步排序 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 root@xtz:~/build# du -h --max-depth 1 | sort -rh 30G . 13G ./lib 13G ./bin 3.6G ./tools 150M ./projects 99M ./utils 11M ./test 8.9M ./CMakeFiles 4.1M ./include 2.7M ./unittests 1.5M ./examples 244K ./cmake 124K ./share 32K ./runtimes 32K ./libexec 32K ./docs 其中 sort 目录的选项 -r 表示逆序，不加 -r 就是顺序；由于前面的 du 使用了 -h 选项，所以 sort 也要启用 -h 选项才可以和 du 结果匹配起来进行排序 df : disk free df 命令则是通过文件系统来快速获取空间大小的信息（如硬盘、分区、挂载点等），用于检查整个文件系统或分区的大小，而不可以做到像 du 那样子针对某一个目录的大小进行分析 当删除一个文件时，该文件并不会立即在文件系统中消失，而是暂时消失，直到所有程序都不再使用它时，才会根据操作系统的规则释放掉 df 命令记录的是通过文件系统获取到的文件大小，包括已经删除但尚未释放的文件，因此在某些情况下比du命令显示的空间要大 至于如何查找删除这些“僵尸文件”，参考这篇博客 当文件系统也确定删除了该文件后，du 和 df 显示的空间大小会一致。使用 df -h 可以以易读的格式显示磁盘空间和使用情况，无论在什么目录下使用 df 得到的结果都是一样的 1 2 3 4 5 6 7 8 root@xtz:~/asanopt/llvm-4.0.0-project/ASanBuild# df -h Filesystem Size Used Avail Use% Mounted on overlay 439G 208G 210G 50% / tmpfs 64M 0 64M 0% /dev shm 64M 0 64M 0% /dev/shm /dev/sda1 439G 208G 210G 50% /etc/hosts tmpfs 32G 0 32G 0% /proc/acpi tmpfs 32G 0 32G 0% /sys/firmware ls -alh 如果想知道某一个文件（而非目录！）的大小，可以使用 ls -alh 命令 -a 表示展示所有信息 -l 表示以一个 list 呈现结果 -h 如上所说，让结果更加符合阅读习惯 1 2 root@xtz:~/asanopt/llvm-4.0.0-project/ASanBuild# ls -alh Makefile -rw-r--r-- 1 root root 919K Nov 23 14:54 Makefile Docker 查看磁盘占用 现在大部分机器都装有容器环境了，有时候查看容器的磁盘占用还是挺重要的，使用 docker system df -v 就可以做到 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 hcy@debian:~/Documents/Windows$ sudo docker system df -v Images space usage: REPOSITORY TAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE CONTAINERS dockurr/windows latest 6dbf20d6f5b1 7 weeks ago 380.4MB 0B 380.4MB 1 Containers space usage: CONTAINER ID IMAGE COMMAND LOCAL VOLUMES SIZE CREATED STATUS NAMES 6270029b27e1 dockurr/windows "/usr/bin/tini -s /r…" 0 5.29MB 2 weeks ago Up 9 seconds windows Local Volumes space usage: VOLUME NAME LINKS SIZE Build cache usage: 0B CACHE ID CACHE TYPE SIZE CREATED LAST USED USAGE SHARED

安装 网上找到的版本应该是这个speccpu2006-v1.0.1-newest.tar，在想要安装的目录下执行tar -xvf speccpu2006-v1.0.1-newest.tar就可以解压安装 进入到目录里面cd speccpu2006-v1.0.1 安装 spec ，./install.sh，如果安装出现错误，极有可能是有一些文件没有可执行文件，递归赋予可执行文件就行chmod -R a+x .，不会有问题的 安装完成之后执行./shrc激活spec环境（以后每次重新打开一个 shell 会话的时候都需要激活一下） 构成 SPEC有两个部分组成，一个是数据，一个是代码（代码以项目的方式组织），运行需要指定数据以及项目 数据有三个规格 test（小型） train（中型） ref（大型） 代码有以下选项 int（整型运算性能） float，也叫 fp（浮点运算性能） all_c（全部 c 项目） all_cpp（全部 cpp 项目） all（全部项目） 特定项目，比如 453.povray 编译标准 C 语言要使用 -std=gnu89 CPP 要使用 -std=c++98 如果要启用 address sanitizer，要注意防止 sanitizer 检测到错误的时候 abort 程序而导致 benchmark 提前终止，需要使用以下编译选项 1 -fsanitize=address -fsanitize-recover=address 并且要注入环境变量ASAN_OPTIONS=halt_on_error=0:detect_leaks=0 配制 运行 spec 需要指定配制，在配制文件里面要声明 reportable = 1 才可以有结果输出 运行模式 spec 有两种运行模式，一个是 base ，基本模式，一般使用这个，一个是 peak ，性能模式，测试峰值性能极限 ...