GDB调试无行号，报dwarf error问题解决_dwarf error wrong version in compilation unit hea

2401_84975387

于 2024-05-15 12:06:52 发布

阅读量821

点赞数 5

分类专栏：程序员文章标签： c语言 c++ 学习

本文链接：https://blog.csdn.net/2401_84975387/article/details/138903195

版权

程序员专栏收录该内容

43 篇文章

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

官方说法是这样的：

Produce debugging information in DWARF format (if that is supported). The value of version may be either 2, 3, 4 or 5; the default version for most targets is 5 (with the exception of VxWorks, TPF and Darwin/Mac OS X, which default to version 2, and AIX, which defaults to version 4).

Note that with DWARF Version 2, some ports require and always use some non-conflicting DWARF 3 extensions in the unwind tables.

Version 4 may require GDB 7.0 and -fvar-tracking-assignments for maximum benefit. Version 5 requires GDB 8.0 or higher.

GCC no longer supports DWARF Version 1, which is substantially different than Version 2 and later. For historical reasons, some other DWARF-related options such as -fno-dwarf2-cfi-asm) retain a reference to DWARF Version 2 in their names, but apply to all currently-supported versions of DWARF.

关于dwarf的调试文件格式，本文就不多做介绍了，如果展开来说，一个专题远远不够。但需要明白的是，各个dwarf版本之间，数据格式也是有所区别的，这也就造成了彼此之间的不兼容，因此才会出现文章开头出现的问题。

如何指定dwarf版本

那么，原因定位到了，我们如何解决这个问题呢？
难不成，我需要降级gcc版本？总不能逼着客户去升级生产环境的gdb版本吧？这明显都是不现实的。
不过好在gcc编译器提供了指定dwarf版本的选项。我们只需要在编译时，增加-gdwarf-version选项即可。
为了演示指定dwarf版本，我在这里准备了一个demo。
C程序如下：

//hello.c
#include <stdio.h>

int main(void){
        char \*p = "hello";
        printf("p = %s\n", p);
        p[3] = 'M';
        printf("p = %s\n", p);
        return 0;
}

容器内gcc版本如下：

[root@5b2c03891f42 tmp]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (GCC)

在容器内编译：

gcc -o hello hello.c -g

该程序一定会产生core文件。我们在容器外运行，此时，这个core文件是无法调试的：

[root@ck08 ctest]# ulimit -c unlimited
[root@ck08 ctest]# ./hello 
p = hello
Segmentation fault (core dumped)
[root@ck08 ctest]# gdb ./hello core.30856 
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/chenyc/src/ctest/hello...Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /root/chenyc/src/ctest/hello]
(no debugging symbols found)...done.
[New LWP 30856]
Core was generated by `./hello'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000401164 in main ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.x86_64
(gdb) bt
#0  0x0000000000401164 in main ()
(gdb)

我们尝试指定dwarf版本编译：

gcc -gdwarf-4 -gstrict-dwarf -fvar-tracking-assignments -o hello hello.c

其中：

-gdwarf-4 指定dwarf版本为4
-fvar-tracking-assignments 在编译的早期对用户变量的赋值进行注释，并尝试在整个编译过程中将注释一直延续到最后，以尝试在优化的同时改进调试信息。
-gstrict-dwarf 禁用更高版本的的dwarf扩展，转而使用指定的dwarf版本的扩展
此时我们可以看到，能够正常调试了。

通过上述的演示，理论上我们只需要在项目编译时，指定dwarf版本，就可以正常调试了。
然而，如果问题如此简单就能解决，那似乎没有必要专门写一篇文章的必要，事实上，我在使用的时候，又遇到了比较玄学的问题。

玄之又玄

截取部分编译输出，可以看到，我的确使用了dwarf-4版本：
在这里插入图片描述

但是我们在运行时，发现仍然报Dwarf Error:

[root@ck08 flow]# gdb ./flow core.10772 
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/chenyc/src/flow/flow...Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /root/chenyc/src/flow/flow]
(no debugging symbols found)...done.
[New LWP 10773]
[New LWP 10774]
[New LWP 10775]
[New LWP 10776]
[New LWP 10772]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./flow'.
#0  0x00007f13b9ae7a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.x86_64
(gdb) bt
#0  0x00007f13b9ae7a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00000000004117d5 in nxlog_worker_thread ()
#2  0x000000000040cdd5 in _thread_helper ()
#3  0x00007f13b9ae3ea5 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f13b9400b0d in clone () from /lib64/libc.so.6
(gdb)

那么，问题出在哪呢？为什么设置了dwarf版本，但是不生效？
为了实锤我们设置的dwarf版本确实生效了，我使用objdump命令查看了一下：

[root@ck08 flow]# objdump --dwarf=info ./flow|more

./flow:     file format elf64-x86-64

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x3e07 (32-bit)
   Version:       4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x31f): GNU C17 11.3.0 -mtune=generic -march=x86-64 -g -gdwarf-4 -gstrict-dwa
rf -O2 -fPIC
    <10>   DW_AT_language    : 12       (ANSI C99)
    <11>   DW_AT_name        : (indirect string, offset: 0x16ac): src/core/protocol.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x1c15): /tmp
    <19>   DW_AT_low_pc      : 0x4090c0
    <21>   DW_AT_high_pc     : 0x127c
    <29>   DW_AT_stmt_list   : 0x0

这里，能看到src/core/protocol.c文件编译出来的二进制文件，dwarf版本确实是4。那么，为什么gdb调试仍然会报dwarf版本是5呢？
那么，会不会是程序依赖的第三方库使用了dwarf-5？
带着疑问，我查看了一下所有的version：
在这里插入图片描述

发现确实有部分二进制文件使用到了dwarf-5版本。
先把dwarf的.debug-info导出来：

objdump --dwarf=info ./flow > dwarf.info

直接定位到754527行：
在这里插入图片描述

可以定位到，是在编译bzip2库的时候，出现了dwarf-5的版本。
为了验证我的猜想，我直接到容器里找到了libbz2,果然它就是罪魁祸首。

[root@5703f261ff2b lib]# objdump --dwarf=info libbz2.a|grep Version
   Version:       5
   Version:       5
   Version:       5
   Version:       5
   Version:       5
   Version:       5
   Version:       5
    <1760>   DW_AT_name        : (indirect string, offset: 0x650): BZ2_bzlibVersion
[root@5703f261ff2b lib]#

那么问题来了，我是在容器里编译第三方依赖的，在编译之前统一设置过CC环境变量：

[root@5703f261ff2b tmp]# echo $CC
gcc -gdwarf-4 -gstrict-dwarf -fvar-tracking-assignments

截取部分Dockerfile内容：
在这里插入图片描述

从Dockerfile可知，我们先设置了CC，然后依次编译openssl， libapr， bzip2，那为什么其他的依赖都没有问题，单单bzip2没有生效呢？

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上C C++开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

链图片转存中…(img-IKFGA3FJ-1715745990041)]
[外链图片转存中…(img-NEyQAACY-1715745990041)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上C C++开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取