clang+llvm多进程gdb调试

BesiseB

已于 2023-11-23 09:38:40 修改

阅读量915

点赞数 3

CC 4.0 BY-SA版权

文章标签： gdb

于 2023-11-22 17:11:34 首次发布

本文链接：https://blog.youkuaiyun.com/B10030607/article/details/134555240

本文介绍了如何在clang+llvm项目中，通过gdb进行多进程调试，包括命令行gdb的使用，父进程和子进程的调试方法，以及在vscode中设置.inc文件高亮。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

clang+llvm多进程gdb调试

前言
1. 命令行gdb
2. 父进程调试
3. 子进程调试
4. 返回父进程
5. .inc文件高亮

前言

在学习新增llvm的优化pass时，需要跟踪clang及llvm的调用栈。然而llvm通过posix_spawn()创建了新进程，这使得gdb调试必须有一定的技巧了。

1. 命令行gdb

以下命令通过clang调用新增优化pass（指令替换），将simple.c文件中的sum函数替换掉：

clang -flegacy-pass-manager -mllvm -sub -mllvm -sub_loop=1 -mllvm -sub_name=sum mvc.o simple.c -o simple

单步调试的命令为：

gdb --args clang -flegacy-pass-manager

最低0.47元/天解锁文章

200万优质内容无限畅学

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

BesiseB

关注关注

3
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

gdb调试llvm源码

格子衫爱上Helloworld

03-26

1992

准备工作安装gdb：链接：https://blog.youkuaiyun.com/weixin_42826139/article/details/88822420 编译llvm的debug类型：链接：https://blog.youkuaiyun.com/weixin_42826139/article/details/88382253 怎么检查是不是编译了llvm的debug类型：gdb clang 这种是编译了d...

用gdb去调试clang

shijiu2012的博客

04-21

5469

做编译器开发的经常会遇到各种问题，有些问题又不是很容易发现而且网上关于gdb调试clang的文章很少，下面简单介绍一下用gdb调试clang供大家学习。 1.首先输入gdb进入调试模式 2.打开要调试的clang可执行文件，通过file命令：等待一会儿将会显示Reading symbols from ~/llvm3.8/bin/clang...done字样 3.设定调...

参与评论您还未登录，请先登录后发表或查看评论

clang的介绍与使用

chenzimin_blog

05-23

1157

Clang 是现代 C/C++ 开发的核心工具，凭借其高性能、清晰的错误提示和强大的工具链（如静态分析、代码格式化），逐渐成为开发者的首选。结合 LLVM 生态，它还可用于代码优化、跨平台编译和定制化开发。对于新手，建议从基础编译命令开始，逐步探索高级功能如 AddressSanitizer 和 clang-format。

GDB 调试

weixin_44917429的博客

09-23

557

通过错误信息我们可以看到是函数 Func 中，test.cpp 的第 8 行出现了错误，于是我们可以打上两个断点，一个在进入 Func 函数时，一个在 test.cpp 文件的第 8 行，并使用。会发现 r 这个 int& 绑定到了一个被解引用的空指针上，所以 &r == nullptr，因此不能读取 r 的值，我们可以用。因为我们在 Func 函数的开头设置了一个断点，所以程序在进入 Func 函数时暂停了；根据刚才的示例程序，可以整理出一些常用的 GDB 命令。对于带参数的程序，我们可以使用。

Clang 与 GCC 编译器的简单比较

DavidWang9527的专栏

03-29

7106

主要整理自知乎上的一个关于clang与gcc优势的讨论.

gdb 调试 llvm 源代码，以 llvm AST 抽象语法树 clang_visitChildren 为例

eloudy的专栏

03-05

461

Makefile：与上一篇的Makefile相似。遍历ast，寻找函数名，并打印。

开发工具：vscode+lldb+clang+cmake c++ 开发环境配置

weixin_41795487的博客

05-25

5298

vscode 下使用插件 CodeLLDB 配置基于 LLDB 的调试环境

centos安装gcc+llvm架构+clang编译器的方法

东方日出西边红

12-18

1179

centos下安装gcc的方法连接到远程服务器 1.从官网下载想要安装的gcc版本 http://ftp.gnu.org/gnu/gcc/ 我下载的gcc-5.5.0版本，没有下载最新的，师兄说最好下载7.0以上的，不过5-5-0版本也能支持llvm,所以就没换。下载之后上传到远程服务器上。 2.解压该文件 tar -xvf gcc-5.5.0.tar.xz 关于这条命令之前输入的是tar xjvf gcc-5.5.0.tar.xz 结果一直报错，上网查了之后改成了-xvf才好...

llvm的安装

格子衫爱上Helloworld

03-10

5866

下载下载地址：https://github.com/llvm/llvm-project 第一种下载，git clone https://github.com/llvm/llvm-project.git,这种是下载的最新的。而且下载下来的是文件夹形式第二种下载，打开https://github.com/llvm/llvm-project找到上面releases，点击，里面有很多旧版本。点击r...

gdb 调试入门

xcw_1987的博客

08-18

2182

参考：gdb 调试入门，大牛写的高质量指南：http://blog.jobbole.com/107759/ 没想到Brendan Gregg这样的大牛，会写出这样一篇gdb tutorials文章：gdb Debugging Full Example (Tutorial): ncurses 。但可能正如文章开头所说，大牛对网上的gdb文章都不太满意，所以才有了这篇高质量指南，gdb入门者的福音...

GDB、LLDB、Clang

buzhidao2333shuosha的博客

11-09

5725

1、GDB和LLDB GDB和LLDB都是调试器，其中LLDB比GDB的功能更加强大。在Mac上使用的是LLDB。 GDB: UNIX及UNIX-like下的调试工具，是GNU项目的调试器部分，旨在与GNU编译器一起工作。 LLDB: LLDB是个开源的内置于XCode的具有REPL(read-eval-print-loop)特征的Debugger，其可以安装C++或者Python插件，是LLVM项目的调试器部分，其创建是为了与LLVM编译器一起使用。二者命令对照表：https://lldb.llvm.o

llvm 编译器学习笔记之二 -- 调试篇

~ 飞扬的天空 ~

10-11

4752

llvm 下构建配置小技巧 1、使能-DLLVM_CCACHE_BUILD=ON ，需要本地ccache工具的支持 llvm 下gdb的小技巧 1、llvm编写了自己的一些实用的类stl库，没有配置过的gdb没法直观的显示这些数据结构的内容在llvm仓下 ./utils/gdb-scripts/prettyprinters.py，在~/.gdbinit中添加source ${path}/prettyprinters.py,就可以较为直观的显示了 2、假如发现clang编译下的stl也无法显示，可..

win10 vscode+clangd代码提示+cmake+mingw编译器和调试器

Howl_1的博客

09-11

2661

cmake+clangd代码提示+mingw编译器和调试器

VSCode+clangd+clang+lldb+cmake配置linux：C/C++开发环境指南（包括生成可执行文件，调试）

a2417962007的博客

10-15

680

{workspaceFolder}可以保留，是当前文件夹的路径变量，注意比对。想要调试F5选择LLDB，但出现问题，显示找不到可执行文件。首先要知道调试的功能由launch.json这个文件实现。是个提示，不是变量，修改成文件名（没必要用变量，麻烦）

[ vscode + clangd + gcc + gdb + cmake] 一文带你构造C/C++开发环境 #支持嵌入式开发 #超详细 #小白

SCP973的博客

11-06

6720

我姥姥都能看懂，超详细，看完就会的 c/c++ 开发环境搭建 vscode + gcc + gdb + CMake + clangd （支持嵌入式开发！）

有时候，使用 clang -g test.c 编译出可执行文件后，发现 gdb a.out 进行调试无法读取符号信息，为什么？

shimly123456的博客

10-03

751

我尝试使用了 16.0.6 版本的 lldb 调试 16.0.6 的 clang 编译出的可执行文件，顺利读取符号信息，如下图。当 gdb 版本为 9.2 时，能支持 9.0.1-12 版本的 clang，当无法支持 16.0.6 版本的 clang。经过测试，gdb 并不是和所有版本的 llvm/clang 都兼容的。可以尝试使用 LLVM 专用的调试器 lldb。

ubuntu16.04 VSCode下cmake+clang+lldb调试c++

qq_41496108的博客

01-21

711

ubuntu16.04 VSCode下cmake+clang+lldb调试c++，clang-format使用

gdb: clang生成的binary无法识别的一个例子

mzhan017的博客

05-10

137

这个就是clang/clang++编译的时候使用了gdb无法识别，不兼容的选项。解决方法，是使用lldb来看coredump文件以及二进制文件。

llvm 学习笔记 1 ：gdb 调试 llvm

beswkwangbo的专栏

03-05

3890

1. 编译出 llvm 系列的 debug 版本，不过据学长说比 release 版要慢 10倍。调试也可以在 release 版输出信息。 2. 使用 -v 参数输出全部的参数信息。clang -flto -c hello.c -v 3. 使用 gdb clang 进入调试阶段。 4. set args + 步骤2 中显示的参数： -cc1 -triple x86_64-unkno

declare i32 @getint() declare void @putint(i32) define i32 @main() { label_entry: %v1 = add i32 1399, 0 %op4 = call i32 @getint() br label %label5 label5: ; preds = %label_entry, %label26 %a = phi i32 [ 1, %label_entry ], [ %a_next, %label26 ] %b = phi i32 [ 1, %label_entry ], [ %b_next, %label26 ] %c = phi i32 [ %op4, %label_entry ], [ %c, %label26 ] %op7 = icmp slt i32 %a, 99999999 br i1 %op7, label %label8, label %label15 label8: ; preds = %label5 %op11 = add i32 %a, %v1 %op13 = srem i32 %op11, %c %op14 = icmp eq i32 %op13, 0 br i1 %op14, label %label18, label %label19 label15: ; preds = %label5 call void @putint(i32 %c) ret i32 %a label18: ; preds = %label8 %b_next1 = add i32 411, 0 br label %label26 label19: ; preds = %label8 %op22 = add i32 %a, %v1 %op24 = srem i32 %op22, %c %op25 = icmp eq i32 %op24, 1 br i1 %op25, label %label32, label %label33 label26: ; preds = %label18, %label40 %b_phi = phi i32 [ %b_next1, %label18 ], [ %b_val40, %label40 ] %op28 = add i32 %a, 1 %op30 = srem i32 %b_phi, 3 %a_next = add i32 %op28, %op30 %b_next = phi i32 [ %b_phi, %label18 ], [ %b_phi, %label40 ] br label %label5 label32: ; preds = %label19 %b_val32 = add i32 101, 0 br label %label40 label33: ; preds = %label19 %op36 = add i32 %a, %v1 %op38 = srem i32 %op36, %c %op39 = icmp eq i32 %op38, 3 br i1 %op39, label %label41, label %label42 label40: ; preds = %label32, %label42 %b_val40 = phi i32 [ %b_val32, %label32 ], [ %b_val42, %label42 ] br label %label26 label41: ; preds = %label33 %b_next3 = add i32 99, 0 br label %label42 label42: ; preds = %label33, %label41 %b_val42 = phi i32 [ %b_next3, %label41 ], [ %b, %label33 ] br label %label40 } sailor@sailor:~/Test/compiler-labs/tests/5-opt/warmup/ll_opt$ clang -O0 -w -no-pie opt-mem2reg-4.ll -o opt-mem2reg-4 -lsysy_io PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/lib/llvm-14/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name opt-mem2reg-4.ll -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -fcoverage-compilation-dir=/home/sailor/Test/compiler-labs/tests/5-opt/warmup/ll_opt -resource-dir /usr/lib/llvm-14/lib/clang/14.0.0 -O0 -w -fdebug-compilation-dir=/home/sailor/Test/compiler-labs/tests/5-opt/warmup/ll_opt -ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/opt-mem2reg-4-f0d56f.o -x ir opt-mem2reg-4.ll 1. Code generation 2. Running pass 'Function Pass Manager' on module 'opt-mem2reg-4.ll'. 3. Running pass 'X86 DAG->DAG Instruction Selection' on function '@main' clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) Ubuntu clang version 14.0.0-1ubuntu1.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. 怎么定位错误的地方？如何查看原因？

最新发布

07-02

<think>我们正在处理一个关于Clang在代码生成阶段发生段错误（Segmentationfault）的调试问题。用户希望定位并分析错误原因，并找到解决方法。根据提供的引用，段错误可能与内存访问越界（如数组越界）或非法内存访问有关。首先，我们需要理解Clang的编译流程。Clang将源代码转换为LLVMIR，然后通过LLVM后端生成目标代码。在代码生成阶段发生段错误，可能是由于编译器本身的bug，或者是由于输入的LLVM IR存在某些问题导致编译器内部错误。调试步骤建议： 1. **缩小问题范围**：尝试将问题简化为最小的可重现测试用例。如果原始代码较大，尝试逐步删除无关部分，直到得到一个仍然能触发段错误的最小代码片段。这有助于定位问题根源。 2. **检查输入文件**：确保输入的LLVMIR文件是有效的。可以使用`opt`（LLVM优化器）对IR文件进行验证和优化，看是否在其他阶段也会触发错误。例如：```bashopt-verify-O0your_file.ll-o /dev/null``` 3. **使用调试符号构建Clang**：为了能够使用调试器（如GDB）跟踪Clang的内部执行，需要构建一个带有调试信息的Clang版本。如果使用的是预编译的Clang，可能需要从源代码构建。4.**使用GDB调试Clang**：在GDB中运行Clang，并让其编译触发错误的源文件或IR文件。当段错误发生时，使用GDB检查堆栈跟踪，以确定错误发生的具体位置。```bashgdb--argsclang-c your_file.ll```在GDB中运行后，当发生段错误时，使用`bt`（backtrace）命令查看堆栈。5.**检查内存错误**：根据引用[2]，段错误可能是由于数组越界等内存访问错误引起。在Clang中，可能是编译器内部在处理某些IR结构时发生了越界访问。通过GDB可以查看崩溃时的内存地址和寄存器状态，帮助分析。 6. **使用AddressSanitizer（ASan）构建Clang**：ASan是一种内存错误检测工具。我们可以构建一个启用了ASan的Clang版本，然后再次运行触发错误的编译过程。ASan可能会捕获到内存访问错误（如越界、使用释放后的内存等）并给出详细报告。```bash#假设在构建LLVM/Clang时，使用CMake，可以添加以下选项：cmake -DLLVM_USE_SANITIZER=Address...```7.**检查已知问题**：在LLVM的bug跟踪系统中搜索相关问题（https://bugs.llvm.org/）。根据崩溃的堆栈信息或简化后的测试用例，查看是否已有相关报告。8.**生成崩溃报告**：如果Clang在崩溃时没有提供足够的信息，可以尝试使用`-v`（verbose）选项来获取更多日志。此外，可以设置环境变量`LLVM_DUMP_COMPILER_OPTIONS`来输出编译器内部选项。 9. **升级或降级Clang版本**：如果当前使用的Clang版本较旧，尝试升级到最新版本，因为问题可能已被修复。如果是最新版本，可以尝试降级到之前的稳定版本来绕过问题。10.**报告Bug**：如果以上步骤无法解决问题，并且发现是一个新的bug，可以向LLVM社区报告，提供最小化的测试用例和详细的崩溃信息。相关问题： 1.如何构建带有调试信息的Clang？ 2.如何使用AddressSanitizer构建Clang？ 3.如何向LLVM社区报告编译器bug？</think>### Clang代码生成阶段Segmentation Fault的调试方法在Clang编译LLVM IR文件时发生Segmentation fault（段错误），通常是由于编译器内部访问了非法内存地址导致的。根据引用[2]，这类错误常与数组越界、空指针解引用或内存访问违规相关。以下是系统化的调试步骤： #### 1. **缩小问题范围** - 创建最小可重现示例：删除无关代码，保留触发段错误的最小IR片段 ```llvm ; 示例：可能触发段错误的IR片段 define i32 @main() { %ptr = alloca i32 store i32 0, i32* %ptr %val = load i32, i32* %ptr ; 正常访问 ret i32 %val } ``` - 测试不同优化级别：`-O0`/`-O1`/`-O2`，观察错误是否与优化相关 #### 2. **启用Clang诊断信息** 使用`-v`选项查看详细编译流程： ```bash clang -v -c your_file.ll -o output.o ``` 重点关注错误发生前的最后操作（如特定优化阶段） #### 3. **使用调试器定位** 通过GDB调试Clang进程（需使用debug版Clang）： ```bash gdb --args clang -c your_file.ll ``` ```gdb (gdb) run Program received signal SIGSEGV, Segmentation fault (gdb) bt # 查看调用栈 (gdb) info registers # 检查寄存器值 (gdb) x/i $pc # 查看崩溃点的汇编指令 ``` #### 4. **内存错误检测工具** - **AddressSanitizer (ASan)**：检测内存访问错误 ```bash clang -fsanitize=address -g your_file.ll -o output ``` - **Valgrind**：分析内存操作 ```bash valgrind --tool=memcheck clang your_file.ll ``` #### 5. **检查IR合法性** 使用LLVM工具验证IR： ```bash opt -verify your_file.ll ``` 若验证失败，说明IR存在结构性问题（如函数签名错误、类型不匹配） #### 6. **常见问题排查** - **指针问题**：检查IR中的指针操作是否越界（引用[2]） - **优化Pass缺陷**：通过`-mllvm -debug-pass=Structure`查看优化流程 - **目标平台兼容性**：检查`target triple`是否与当前架构匹配 - **版本冲突**：确认Clang/LLVM版本是否一致 #### 7. **高级调试手段** - **生成崩溃转储**： ```bash ulimit -c unlimited clang your_file.ll # 崩溃后生成core文件 gdb clang core # 分析转储 ``` - **LLDB脚本化调试**： ```bash lldb --batch -o "run" -k "thread backtrace" clang your_file.ll ``` #### 8. **问题上报** 若确定为编译器bug，向LLVM社区提交报告： 1. 包含最小可重现IR 2. 附上GDB的`bt full`输出 3. 注明Clang版本：`clang --version` 4. 目标平台信息：`uname -a` > **关键提示**：当GDB显示类似`0x00000000602296ac in static_code_gen_buffer()`（引用[1]）的地址时，表明错误发生在代码生成缓冲区操作中，可能涉及机器码生成阶段的内部数据结构损坏。