[英]gcc debug symbols (-g flag) vs linker's -rdynamic option
glibc provides backtrace()
and backtrace_symbols()
to get the stack trace of a running program. glibc提供了
backtrace()
和backtrace_symbols()
来获取正在运行的程序的堆栈跟踪。 But for this to work the program has to be built with linker's -rdynamic
flag. 但为了实现这一点,程序必须使用链接器的
-rdynamic
标志构建。
What is the difference between -g
flag passed to gcc vs linker's -rdynamic
flag ? 是什么区别
-g
传递给GCC VS链接的标志-rdynamic
标志? For a sample code I did readelf to compare the outputs. 对于示例代码,我做了readelf来比较输出。
-rdynamic
seems to produce more info under Symbol table '.dynsym'
But I am not quite sure what the additional info is. -rdynamic
似乎在Symbol table '.dynsym'
下产生更多信息但是我不太确定附加信息是什么。
Even if I strip
a program binary built using -rdynamic
, backtrace_symbols()
continue to work. 即使我
strip
了使用-rdynamic
构建的程序二进制文件, backtrace_symbols()
也会继续工作。
When strip
removes all the symbols from the binary why is it leaving behind whatever was added by the -rdynamic
flag ? 当
strip
从二进制文件中删除所有符号时,为什么它会留下-rdynamic
标志添加的内容?
Edit: Follow-up questions based on Mat's response below.. 编辑:基于Mat的回复的后续问题如下..
For the same sample code you took this is the difference I see with -g
& -rdynamic
对于相同的示例代码,您使用的是与
-g
和-rdynamic
的区别
without any option.. 没有任何选择..
Symbol table '.dynsym' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 218 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
3: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
Symbol table '.symtab' contains 70 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000400200 0 SECTION LOCAL DEFAULT 1
2: 000000000040021c 0 SECTION LOCAL DEFAULT 2
with -g
there are more sections, more entries in .symtab
table but .dynsym
remains the same.. 与
-g
有更多的部分, .symtab
表中的更多条目,但.dynsym
保持不变..
[26] .debug_aranges PROGBITS 0000000000000000 0000095c
0000000000000030 0000000000000000 0 0 1
[27] .debug_pubnames PROGBITS 0000000000000000 0000098c
0000000000000023 0000000000000000 0 0 1
[28] .debug_info PROGBITS 0000000000000000 000009af
00000000000000a9 0000000000000000 0 0 1
[29] .debug_abbrev PROGBITS 0000000000000000 00000a58
0000000000000047 0000000000000000 0 0 1
[30] .debug_line PROGBITS 0000000000000000 00000a9f
0000000000000038 0000000000000000 0 0 1
[31] .debug_frame PROGBITS 0000000000000000 00000ad8
0000000000000058 0000000000000000 0 0 8
[32] .debug_loc PROGBITS 0000000000000000 00000b30
0000000000000098 0000000000000000 0 0 1
Symbol table '.dynsym' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 218 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
3: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
Symbol table '.symtab' contains 77 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000400200 0 SECTION LOCAL DEFAULT 1
with -rdynamic
no additional debug sections, .symtab entries are 70 (same as vanilla gcc invocation), but more .dynsym
entries.. 与
-rdynamic
没有额外的调试节,的.symtab条目是70(同香草GCC调用),但更多的.dynsym
条目..
Symbol table '.dynsym' contains 19 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 218 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
2: 00000000005008e8 0 OBJECT GLOBAL DEFAULT ABS _DYNAMIC
3: 0000000000400750 57 FUNC GLOBAL DEFAULT 12 __libc_csu_fini
4: 00000000004005e0 0 FUNC GLOBAL DEFAULT 10 _init
5: 0000000000400620 0 FUNC GLOBAL DEFAULT 12 _start
6: 00000000004006f0 86 FUNC GLOBAL DEFAULT 12 __libc_csu_init
7: 0000000000500ab8 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
8: 00000000004006de 16 FUNC GLOBAL DEFAULT 12 main
9: 0000000000500aa0 0 NOTYPE WEAK DEFAULT 23 data_start
10: 00000000004007c8 0 FUNC GLOBAL DEFAULT 13 _fini
11: 00000000004006d8 6 FUNC GLOBAL DEFAULT 12 foo
12: 0000000000500ab8 0 NOTYPE GLOBAL DEFAULT ABS _edata
13: 0000000000500a80 0 OBJECT GLOBAL DEFAULT ABS _GLOBAL_OFFSET_TABLE_
14: 0000000000500ac0 0 NOTYPE GLOBAL DEFAULT ABS _end
15: 00000000004007d8 4 OBJECT GLOBAL DEFAULT 14 _IO_stdin_used
16: 0000000000500aa0 0 NOTYPE GLOBAL DEFAULT 23 __data_start
17: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
18: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
Symbol table '.symtab' contains 70 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000400200 0 SECTION LOCAL DEFAULT 1
2: 000000000040021c 0 SECTION LOCAL DEFAULT 2
Now these are the questions I have.. 现在这些是我的问题..
In gdb you can do bt to get the bactrace. 在gdb中你可以做bt来获得bactrace。 If that works with just
-g
why do we need -rdynamic
for backtrace_symbols to work ? 如果只使用
-g
为什么我们需要-rdynamic
来使用backtrace_symbols?
Comparing the additions to .symtab
with -g
& additions to .dynsym
with -rdynamic
they are not exactly the same.. Does either one provide better debugging info compared to the other ? 比较补充
.symtab
与-g
和补充, .dynsym
与-rdynamic
他们是不完全一样的..一方是否提供更好的调试信息相比其他? FWIW, size of the output produced is like this: with -g > with -rdynamic > with neither option FWIW,产生的输出大小如下:使用-g> with -rdynamic>且没有选项
What exactly is the usage of .dynsym ? .dynsym的用途究竟是什么? Is it all the symbols exported by this binary ?
是这个二进制文件导出的所有符号吗? In that case why is foo going into .dynsym because we are not compiling the code as a library.
在那种情况下,为什么foo会进入.dynsym,因为我们没有将代码编译为库。
If I link my code using all static libraries then -rdynamic is not needed for backtrace_symbols to work ? 如果我使用所有静态库链接我的代码,那么backtrace_symbols不需要-rdynamic吗?
According to the docs: 根据文件:
This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table.
这指示链接器将所有符号(不仅是已使用的符号)添加到动态符号表中。
Those are not debug symbols, they are dynamic linker symbols. 那些不是调试符号,它们是动态链接器符号。 Those are not removed by
strip
since it would (in most cases) break the executable - they are used by the runtime linker to do the final link stage of your executable. 这些不会被
strip
删除,因为它会(在大多数情况下)破坏可执行文件 - 运行时链接程序使用它们来执行可执行文件的最后一个链接阶段。
Example: 例:
$ cat t.c
void foo() {}
int main() { foo(); return 0; }
Compile and link without -rdynamic
(and no optimizations, obviously) 不
-rdynamic
编译和链接(显然没有优化)
$ gcc -O0 -o t t.c
$ readelf -s t
Symbol table '.dynsym' contains 3 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
Symbol table '.symtab' contains 50 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000400270 0 SECTION LOCAL DEFAULT 1
....
27: 0000000000000000 0 FILE LOCAL DEFAULT ABS t.c
28: 0000000000600e14 0 NOTYPE LOCAL DEFAULT 18 __init_array_end
29: 0000000000600e40 0 OBJECT LOCAL DEFAULT 21 _DYNAMIC
So the executable has a .symtab
with everything. 所以可执行文件有一个包含所有内容的
.symtab
。 But notice that .dynsym
doesn't mention foo
at all - it has the bare essentials in there. 但请注意,
.dynsym
根本没有提到foo
- 它在那里有最基本的要点。 This is not enough information for backtrace_symbols
to work. 这不足以让
backtrace_symbols
工作。 It relies on the information present in that section to match code addresses with function names. 它依赖于该部分中的信息来匹配代码地址和函数名称。
Now compile with -rdynamic
: 现在用
-rdynamic
编译:
$ gcc -O0 -o t t.c -rdynamic
$ readelf -s t
Symbol table '.dynsym' contains 17 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
3: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
4: 0000000000601018 0 NOTYPE GLOBAL DEFAULT ABS _edata
5: 0000000000601008 0 NOTYPE GLOBAL DEFAULT 24 __data_start
6: 0000000000400734 6 FUNC GLOBAL DEFAULT 13 foo
7: 0000000000601028 0 NOTYPE GLOBAL DEFAULT ABS _end
8: 0000000000601008 0 NOTYPE WEAK DEFAULT 24 data_start
9: 0000000000400838 4 OBJECT GLOBAL DEFAULT 15 _IO_stdin_used
10: 0000000000400750 136 FUNC GLOBAL DEFAULT 13 __libc_csu_init
11: 0000000000400650 0 FUNC GLOBAL DEFAULT 13 _start
12: 0000000000601018 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
13: 000000000040073a 16 FUNC GLOBAL DEFAULT 13 main
14: 0000000000400618 0 FUNC GLOBAL DEFAULT 11 _init
15: 00000000004007e0 2 FUNC GLOBAL DEFAULT 13 __libc_csu_fini
16: 0000000000400828 0 FUNC GLOBAL DEFAULT 14 _fini
Symbol table '.symtab' contains 50 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000400270 0 SECTION LOCAL DEFAULT 1
....
27: 0000000000000000 0 FILE LOCAL DEFAULT ABS t.c
28: 0000000000600e14 0 NOTYPE LOCAL DEFAULT 18 __init_array_end
29: 0000000000600e40 0 OBJECT LOCAL DEFAULT 21 _DYNAMIC
Same thing for symbols in .symtab
, but now foo
has a symbol in the dynamic symbol section (and a bunch of other symbols appear there now too). 同样适用于
.symtab
中的符号,但现在foo
在动态符号部分中有一个符号(现在也出现了一堆其他符号)。 This makes backtrace_symbols
work - it now has enough information (in most cases) to map code addresses with function names. 这使得
backtrace_symbols
工作 - 它现在有足够的信息(在大多数情况下)用函数名映射代码地址。
Strip that: 除去:
$ strip --strip-all t
$ readelf -s t
Symbol table '.dynsym' contains 17 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
3: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
4: 0000000000601018 0 NOTYPE GLOBAL DEFAULT ABS _edata
5: 0000000000601008 0 NOTYPE GLOBAL DEFAULT 24 __data_start
6: 0000000000400734 6 FUNC GLOBAL DEFAULT 13 foo
7: 0000000000601028 0 NOTYPE GLOBAL DEFAULT ABS _end
8: 0000000000601008 0 NOTYPE WEAK DEFAULT 24 data_start
9: 0000000000400838 4 OBJECT GLOBAL DEFAULT 15 _IO_stdin_used
10: 0000000000400750 136 FUNC GLOBAL DEFAULT 13 __libc_csu_init
11: 0000000000400650 0 FUNC GLOBAL DEFAULT 13 _start
12: 0000000000601018 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
13: 000000000040073a 16 FUNC GLOBAL DEFAULT 13 main
14: 0000000000400618 0 FUNC GLOBAL DEFAULT 11 _init
15: 00000000004007e0 2 FUNC GLOBAL DEFAULT 13 __libc_csu_fini
16: 0000000000400828 0 FUNC GLOBAL DEFAULT 14 _fini
$ ./t
$
Now .symtab
is gone, but the dynamic symbol table is still there, and the executable runs. 现在
.symtab
已经消失,但动态符号表仍然存在,可执行文件运行。 So backtrace_symbols
still works too. 所以
backtrace_symbols
仍然有效。
Strip the dynamic symbol table: 剥离动态符号表:
$ strip -R .dynsym t
$ ./t
./t: relocation error: ./t: symbol , version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
... and you get a broken executable. ......你得到一个破碎的可执行文件。
An interesting read for what .symtab
and .dynsym
are used for is here: Inside ELF Symbol Tables . 有关
.symtab
和.dynsym
用于什么的有趣读物如下: 内部ELF符号表 。 One of the things to note is that .symtab
is not needed at runtime, so it is discarded by the loader. 需要注意的一点是,运行时不需要
.symtab
,因此加载器会丢弃它。 That section does not remain in the process's memory. 该部分不会留在进程的内存中。
.dynsym
, on the otherhand, is needed at runtime, so it is kept in the process image. .dynsym
,在otherhand, 需要在运行时间,所以它保持在处理图像英寸 So it is available for things like backtrace_symbols
to gather information about the current process from within itself. 因此,它可用于
backtrace_symbols
东西,以从内部收集有关当前进程的信息。
So in short: 简而言之:
strip
since that would render the executable non-loadable strip
剥离,因为这会使可执行文件不可加载 backtrace_symbols
needs dynamic symbols to figure out what code belongs which function backtrace_symbols
需要动态符号来确定哪些代码属于哪个函数 backtrace_symbols
does not use debugging symbols backtrace_symbols
不使用调试符号 Hence the behavior you noticed. 因此你注意到的行为。
For your specific questions: 针对您的具体问题:
gdb
is a debugger. gdb
是一个调试器。 It uses debug information in the executable and libraries to display relevant information. backtrace_symbols
, and inspects the actual files on your drive in addition to the live process. backtrace_symbols
,并检查除了直播过程中您的驱动器上的实际文件。 backtrace_symbols
does not, it is entirely in-process - so it cannot access sections that are not loaded into the executable image. backtrace_symbols
没有,它完全处于进程中 - 因此它无法访问未加载到可执行映像中的部分。 Debug sections are not loaded into the runtime image, so it can't use them. .dynsym
is not a debugging section. .dynsym
不是调试部分。 It is a section used by the dynamic linker. .symbtab
isn't a debugging section either, but it can be used by debugger that have access to the executable (and library) files. .symbtab
也不是调试部分,但可以由可以访问可执行(和库)文件的调试器使用。 -rdynamic
does not generate debug sections, only that extended dynamic symbol table. -rdynamic
不生成调试节,只生成扩展的动态符号表。 The executable growth from -rdynamic
depends entirely on the number of symbols in that executable (and alignment/padding considerations). -rdynamic
的可执行增长完全取决于该可执行文件中的符号数(以及对齐/填充注意事项)。 It should be considerably less than -g
. -g
。 printf
and some application startup procedures from the C library. printf
和一些应用程序启动过程一样。 These external symbols must be indicated somewhere in the executable: this is what .dynsym
is used for, and this is why the exe has a .dynsym
even if you don't specify -rdynamic
. .dynsym
的用途,这就是为什么exe文件有一个.dynsym
即使你不指定-rdynamic
。 When you do specify it, the linker adds other symbols that are not necessary for the process to work, but can be used by things like backtrace_symbols
. backtrace_symbols
类的东西使用。 backtrace_symbols
will not resolve any function names if you statically link. backtrace_symbols
将不会解析任何函数名称。 Even if you specify -rdynamic
, the .dynsym
section will not be emitted to the executable. -rdynamic
,该.dynsym
部分将不发射到可执行文件。 No symbol tables gets loaded into the executable image, so backtrace_symbols
cannot map code adresses to symbols. backtrace_symbols
无法将代码地址映射到符号。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.