GCC Coverage代码分析-GCC插桩基本概念及原理分析

最新推荐文章于 2024-06-08 06:23:55 发布
原创 最新推荐文章于 2024-06-08 06:23:55 发布 · 9.9k 阅读 · 8 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#gcc #代码分析 #汇编 #测试 #linux #reference

本文详细阐述了GCC插桩的基本概念和原理，包括编译过程中的插桩步骤，插桩位置的选择，以及如何通过GCC编译选项实现插桩。通过插桩收集程序执行信息，用于代码覆盖率测试。GCC主要在汇编阶段插入桩代码，并通过.gcno和.gcda文件记录执行数据。
本博客（ http://blog.youkuaiyun.com/livelylittlefish）贴出作者（阿波）相关研究、学习内容所做的笔记，欢迎广大朋友指正！

Content

1. 序

2. GCC插桩原理

2.1 GCC编译插桩的过程

2.2 GCC在何处插桩

2.3 GCC如何才能在编译的同时插桩

3. 小结

 

 

1.序

 

在"Linux平台代码覆盖率测试-GCC插桩前后汇编代码对比分析"一文，我们已经分析了GCC插桩前后汇编代码的变化，对GCC插入的桩代码有比较全面的了解。本文将简单叙述GCC插桩的基本概念和原理。

 

2. GCC插桩原理

 

2.1 GCC编译插桩的过程

 

最低0.47元/天 解锁文章

200万优质内容无限畅学
Linux平台下的代码覆盖率测试：GCC插桩的基本概念和原理分析
2301_79331387的博客
10-08 554
通过在关键位置插入计数器和跟踪代码，可以统计代码的执行次数，从而计算出代码的覆盖率。通过在关键位置插入计数器和跟踪代码，可以统计代码的执行次数，从而计算出代码的覆盖率。分析覆盖率：最后，通过分析计数器和跟踪代码的信息，可以计算出代码的覆盖率。分析覆盖率：最后，通过分析计数器和跟踪代码的信息，可以计算出代码的覆盖率。在执行过程中，计数器会记录代码的执行次数，跟踪代码会记录执行的路径。在执行过程中，计数器会记录代码的执行次数，跟踪代码会记录执行的路径。插入计数器：在确定的位置，GCC会插入计数器代码。
深入解析编译器插桩：探索编译原理
UaCode的博客
09-27 332
编译器插桩是一种强大的工具，可以在编译过程中实现各种功能，从而提升软件开发和调试的效率。编译器插桩是一种在编译过程中向源代码中插入额外代码的技术，用于实现各种目的，如性能分析、调试、代码覆盖率统计等。通过这种方式，我们可以在不改变源代码的情况下，实现对目标代码的功能扩展。函数的内部插入了一条打印语句，用于输出额外的信息。编译器插桩的核心思想是在源代码的特定位置插入额外的代码，以实现所需的功能。代码覆盖率统计：通过在源代码或目标代码中插入统计代码，可以统计代码的执行情况，帮助开发人员评估测试用例的覆盖率。
GCC Coverage代码分析-基本块图、插桩位置及桩代码执行分析
学习，思考，记录，分享。
05-27 9528
本博客（http://blog.youkuaiyun.com/livelylittlefish）贴出作者（阿波）相关研究、学习内容所做的笔记，欢迎广大朋友指正！Content0. 序1. 基本块概念2. 基本块图及插桩点分析2.1 基本块图2.2 有效基本块图2.3 带桩点信息的有效基本块图2.4 插桩位置及桩代码执行情况分析3. 小结Appendix:源代码中对Basic Block的解释  0.序 由前面
GCC Coverage代码分析-GCC插桩前后汇编代码对比分析
学习，思考，记录，分享。
05-27 8739
本博客（http://blog.youkuaiyun.com/livelylittlefish）贴出作者（阿波）相关研究、学习内容所做的笔记，欢迎广大朋友指正！Content0. 序1. 如何编译1.1 未加入覆盖率测试选项1.2 加入覆盖率测试选项1.3 分析2. 未加入覆盖率测试选项的汇编代码分析3. 加入覆盖率测试选项的汇编代码分析3.1 计数桩代码分析3.2 构造函数桩代码分析3.3 数据结构分析3.
AFL源码阅读笔记（一）—— gcc 普通插桩
weixin_45651194的博客
11-25 1156
afl源码阅读记录，包括一些前置知识的介绍，参考目前网上的主流博客和自己的体会。
GCC Coverage代码分析-编译过程自动化及对链接的解释
热门推荐
学习，思考，记录，分享。
05-27 1万+
本博客（http://blog.youkuaiyun.com/livelylittlefish）贴出作者（阿波）相关研究、学习内容所做的笔记，欢迎广大朋友指正！Content0. 序1. 生成各个文件的步骤1.1 未加入覆盖率测试选项1.1.1 编译步骤1.1.2 目标文件的符号表1.2 加入覆盖率测试选项1.2.1 编译步骤1.2.2 目标文件的符号表1.3 gcc verbose选项2. 编译自动化2.1
GCC Coverage代码分析-GCC如何编译生成gcov/gcov-dump程序及其bug分析
学习，思考，记录，分享。
05-01 9915
本博客（http://blog.youkuaiyun.com/livelylittlefish）贴出作者（阿波）相关研究、学习内容所做的笔记，欢迎广大朋友指正！ Content 0. 序 1.编译gcov/gcov-dump 2. 额外的话 3. gcov-dump程序的一
Linux: dev: gcc: gcoverage；代码运行时的覆盖率
mzhan017的博客
12-28 687
前些天写到gcc的instrument，https://mzhan017.blog.youkuaiyun.com/article/details/135098562；今天看到这个就是属于这一类，查看代码运行时的覆盖率的功能。可以帮助查看代码运行时的覆盖率需要编译时带上 --coverage选项加上这个之后，gcc编译时就会添加一些全局计数，比如下面的汇编。从文档里看，需要将优化选项去掉，不然有些优化可能导致统计问题。
动态二进制分析与插桩原理介绍(PDF)
12-02
老外的演讲稿(PDF)，主要是介绍了二进制插桩的原理与实现，然后举了一些例子来加以讲解分析。英文太渣的童鞋就自己翻译下再阅读吧~~~
基于GCC的嵌入式程序插装技术
01-19
本文介绍一种通过分析和修改GCC编译工具，实现程序插装的新方法。该方法具有批量自动插装，插装与编译连接紧密结合，适用语言广泛等优点。具体讨论了如何在ARM嵌入式程序中实现程序插装，并给出修改GCC的源代码。       引 言 　　程序插装(Program Instrumentation)概念是由J．G．Huang教授提出，是借助往被测程序中插入操作(称为“探针”)，以便获取程序的控制流和数据流信息，从而实现测试目的的方法。在软件动态测试中，程序插装是一种基本的测试手段，应用广泛，是覆盖率测试、软件故障注入和动态性能分析的基础技术。 　　GCC(GNU Compiler Collect
C/C++/Linux函数函数插桩(打桩)指南
08-12
在具有一定规模的代码中(C 语言)，调用第三方动态库中的函数来完成一些功能，是很常见的工作场景。 假设现在有一项任务：需要在调用某个动态库中的某个函数的之前和之后，做一些额外的处理工作。 这样的需求一般称作：插桩，也就是对于一个指定的目标函数，新建一个包装函数，来完成一些额外的功能，如动态调试等。 本文主要讲解什么是打桩，以及编译阶段打桩、链接阶段打桩、执行阶段打桩三种方式。
gcc: coverage: gcda文件没有生成另一例：so文件调用__gcov_dump
mzhan017的博客
06-08 767
那么会造成一个问题，如果想通过so中的某个函数调用gcov_do_dump，会调用so内部的。所以导致某些gcda文件生成不出来。这个时候主程序也是有用–coverage编译链接，那么也会含有一套这个函数。原因是gcc提供的libgcov库是一个静态库。这个so文件里带有gcov需要的很多函数/全局变量（符号），包括gcov_dump，gcov_var，。所以要避免这种方式，最好是不要在so文件里有这些gcov的函数定义。如果使用gcc --coverage选项编译出一个so文件。
使用gcc/g++的--coverage查看代码的覆盖测试（使用VSCode）
爱就是是恒久忍耐的专栏
10-02 4825
使用gcc/g++的--coverage查看代码的覆盖测试
让数据大白于天下：GCC插件实现代码分析和安全审计
华为云官方博客
12-16 4808
摘要：如何利用GCC的插件功能，辅助安全分析人员实现对程序的安全审计、漏洞检测、安全加固等自动化处理能力，提升分析效率和精准度。
利用GCC插件实现代码分析和安全审计
m0_73078430的博客
09-01 194
但如果能预先在目标程序中把插装代码编译进去，这样既兼顾到性能，有兼顾到实现插装的目的，一般要实现这个目的都是在源代码层面由开发人员增加插装代码，但增加的代码只是为了测试的目的，在实际发布版本中是不需要的，因此直接在源代码层面增加插装代码就给代码维护带来的不便，但如果我们应用GCC编译器的插件能力，在编译构建过程中自动添加插装代码到最终生成的二进制文件中，这样只需根据需要重新编译就能得到不同目的的应用程序而不需要修改任何一行源代码，既增加插装代码的动作对上层是透明的。......
GCC Coverage代码分析-gcov-dump原理分析
学习，思考，记录，分享。
05-27 1万+
本博客（http://blog.youkuaiyun.com/livelylittlefish）贴出作者（阿波）相关研究、学习内容所做的笔记，欢迎广大朋友指正！Content1.序2. gcov-dump原理分析2.1 gcov-dump程序结构2.2 dump_file函数分析2.3处理各种tag的callback定义2.4基本读取函数gcov_read_words2.5分配空间函数gcov_allocat
测试代码覆盖率-GCOV的使用
guo8113的专栏
08-03 2568
测试代码覆盖率-GCOV的使用
使用程序分析工具获取软件的基本块数量和边数量
最新发布
05-29
<think>嗯，用户现在想用程序分析工具来获取软件控制流图中的基本块数量和边的数量。之前我已经解释了如何计算基本块数量，现在用户需要具体的工具和方法来实现这一点。我需要结合之前的回答和新的引用内容来给出解决方案。首先，用户提到的引用里提到CFG是在IR上建立的，比如LLVM IR，还有Soot生成的Jimple。所以可能需要用静态分析工具处理这些中间表示。比如LLVM的opt工具可以生成CFG，或者用Clang生成LLVM IR，然后分析其中的基本块。另外，引用5提到静态分析的原材料是3AC-IR，比如Soot的Jimple，所以可能需要用Soot来分析Java程序。 接下来，用户可能需要具体的步骤，比如使用LLVM的命令行工具，或者编写代码遍历基本块和边。例如，用LLVM的API写一个pass来统计基本块数量，以及每个基本块的后继数量，从而得到边的总数。或者用GCC的-fdump-tree-cfg选项来生成CFG的图，然后解析输出文件。 动态分析工具可能不太直接，因为动态分析通常是在运行时跟踪执行路径，可能无法覆盖所有边。但结合覆盖率工具如gcov，可以获取执行过的基本块，但可能无法得到完整的CFG边数。不过用户可能更关注静态分析工具，因为动态分析可能无法覆盖所有情况。 另外，用户提到的引用4提到APK文件中的调用图处理，可能需要用androguard这样的工具分析Android应用，但问题可能更偏向于一般的程序分析。所以重点还是放在静态分析工具如LLVM、Soot、GCC等。 需要分步骤说明：使用工具生成CFG，然后如何提取基本块和边的数量。比如用LLVM的opt-view-cfg可以可视化，同时输出文本信息，或者用GCC的dump文件。然后可能用脚本或代码解析这些输出，统计节点和边。还要注意不同的语言可能需要不同的工具，比如C/C++用LLVM/GCC，Java用Soot，Python可能用特定的分析工具。用户可能需要根据目标软件的语言选择合适的工具。最后，生成相关问题，可能涉及优化、工具比较、结果解读等。比如如何利用基本块数量优化性能，不同工具的优缺点，或者边数量与代码复杂度的关系。</think>### 如何通过程序分析工具获取控制流图的基本块与边数量 #### 一、静态分析工具实现 ##### 1. LLVM/Clang工具链 **步骤1：生成LLVM IR** ```bash clang -S -emit-llvm example.c -o example.ll ``` **步骤2：使用`opt`分析CFG** ```bash opt -analyze -view-cfg example.ll 2>&1 | grep "BasicBlock" ``` 输出示例： ``` BasicBlock %entry (0x7f8e3b808000) BasicBlock %if.then (0x7f8e3b8080a0) BasicBlock %if.else (0x7f8e3b8080c0) BasicBlock %if.end (0x7f8e3b8080e0) ``` 统计`BasicBlock`数量即为基本块总数[^1][^5]。 **步骤3：统计边数量** 通过LLVM API遍历前驱/后继关系： ```cpp #include <llvm/IR/CFG.h> int countEdges(BasicBlock *BB) { return std::distance(succ_begin(BB), succ_end(BB)); } // 遍历所有基本块的succ数量求和 ``` ##### 2. Soot（Java程序分析） **步骤1：生成Jimple中间表示** ```java java -cp soot.jar soot.Main -pp -f J simple.Java ``` **步骤2：构建CFG并统计** 通过`UnitGraph`接口获取边信息： ```java UnitGraph cfg = new ExceptionalUnitGraph(body); int nodeCount = cfg.size(); // 基本块数量 int edgeCount = cfg.getEdges().size(); // 边数量 ``` #### 二、动态分析辅助 ##### 1. GCOV覆盖率分析 ```bash gcc -fprofile-arcs -ftest-coverage example.c ./a.out gcov -b example.c ``` `example.c.gcov`文件中包含： - **基本块执行次数**（`#####`表示未覆盖） - **边转移概率**（通过分支覆盖率推断） ##### 2. PIN工具（二进制插桩） 通过插桩统计执行路径： ```cpp VOID Trace(TRACE trace, VOID *v) { for (BBL bbl = TRACE_BblHead(trace); BBL_Valid(bbl); bbl = BBL_Next(bbl)) { basic_block_count++; // 动态执行的基本块数量 } } ``` #### 三、关键指标计算 | 指标 | 计算方法 | 工具示例 | |--------------|----------------------------|----------------| | 基本块数量 | 统计CFG节点数 | LLVM `opt`[^5] | | 边数量 | 统计所有基本块的后继总数 | Soot `UnitGraph`[^5] | | 边密度 | $\frac{\text{边数量}}{\text{基本块数量}}$ | GCOV + 脚本 | #### 四、典型输出示例 **LLVM CFG分析结果** ``` 函数名: @example 基本块数量: 4 边数量: 4 (entry→if.then, entry→if.else, if.then→if.end, if.else→if.end) ``` **Java Soot分析结果** ``` 方法: void main(String[]) 基本块数量: 7 边数量: 9 (包含异常处理边) ``` #### 五、工具对比 | 工具类型 | 优点 | 局限性 | |------------|-------------------------------|---------------------------| | LLVM | 支持跨语言，精度高 | 需要源码编译为LLVM IR[^5] | | Soot | 直接处理Java字节码 | 不适用Native代码 | | GCOV | 提供运行时覆盖信息 | 无法获取完整CFG | | PIN | 支持二进制程序 | 性能开销大 |
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值