CALL STACK TRACE GENERATION
来源:互联网 发布:apache服务器安装包 编辑:程序博客网 时间:2024/05/22 05:17
原文发表在http://www.acsu.buffalo.edu/~charngda/backtrace.html(链接已失效),转载自http://cdunn2001.blogspot.com/2012_05_01_archive.html
Call stack trace ("backtrace") is very useful in debugging. Here are several ways to retrieve the backtrace in a user program.
(The contents are mostly from here and here)
EASIEST APPROACH: __BUILTIN_RETURN_ADDRESS
GCC has a built-in function to retrieve call stack trace's addresses. For example
__builtin_return_address(0) is always current function's address. On the other hand,__builtin_return_address(1), __builtin_return_address(2), ... may not be available on all platforms.
WHAT TO DO WITH THESE ADDRESSES ?
Addresses can be mapped to the binary executable or dynamic link libraries. This is always doable even if the binary executable has been stripped off the symbols.
To see the mapping during runtime, parse the following plain-text file on the /proc file system:
/proc/self/maps
A utility called pmap can do the same.
If the address belongs to a DLL, it is possible to obtain the function name since DLLs are usually not stripped.
Addresses can be mapped to function names. Even if a binary executable is compiled without -g option, it still contains function names. To see the function names in the binary executable, do
nm -C -n a.out
To see the function names programmatically in the binary executable during run-time, read later paragraphs.
Addresses can be mapped to line numbers in source files. This extra information (in DWARF format) is added to the binary executable if it is compiled with -g option. To see line numbers in source files, do
objdump -WL a.out
objdump --dwarf=decodedline a.out
or even better:
addr2line -ifC a.out 0x123456
where 0x123456 is the address of interest. To see line numbers in source files programmatically during run-time, read later paragraphs.
APPROACH 2: BACKTRACE
backtrace and backtrace_symbols are functions in Glibc. To use backtrace_symbols, one must compile the program with -rdynamic option.
One does not need to compile with -g option (but -rdynamic option cannot be used together with -static option) since backtrace_symbols cannot retrieve line number information. Actually, one can even strip off the symbols, and the backtrace_symbols will still work. This is because when -rdynamic is used, all global symbols are also stored in .dynsym section in the ELF-formatted executable binary, and this section cannot be stripped away. (To see the content of .dynsym section, use readelf -s a.out command, or readelf -p .dynstr a.outcommand.)
backtrace_symbols obtains symbol information from .dynsym section.
(The main purpose of .dynsym section is for dynamic link libraries to expose their symbols so the runtime linker ld.so can find them.)
Here is the sample program:
For C++ programs, to get demangled names, use abi::__cxa_demangle (include the headercxxabi.h)
APPROACH 3: IMPROVED BACKTRACE
The backtrace_symbols in Glibc uses dladdr to obtain function names, but it cannot retrieve line numbers. Jeff Muizelaar has an improved version here which can do line numbers.
If the user program is compiled without any special command-line options, then one can obtain function names (of course, provided the binary executable is not stripped.) Better yet, -rdynamic compiler option is not needed.
If the user program is compiled with -g option, one can obtain both line numbers and function names.
Note that to compile Jeff Muizelaar's backtrace_symbols implementation, make sure the following two macros are defined and appears as the first two lines of a user program (they must precede before all #include ...):
#define __USE_GNU
#define _GNU_SOURCE
and one needs Binary File Descriptor (BFD) library, which is now part of GNU binutils when linking Jeff's code to the user program.
APPROACH 4: LIBUNWIND
libunwind does pretty much what the original backtrace/backtrace_symbols do. Its main purpose, however, is to unwind the stack programmatically (even more powerful thansetjmp/longjmp pair) through unw_step and unw_resume calls. One can also peek and modify the saved register values on stack via unw_get_reg, unw_get_freg, unw_set_reg, and unw_set_freg calls.
If one just wants to retrieve the backtrace, use the following code:
and linked the user program with -lunwind -lunwind-x86_64.
There is no need to compile the user program with -g option.
POSTED BY CHRISTOPHER DUNN AT 11:24 AM 0 COMMENTS
- CALL STACK TRACE GENERATION
- CALL STACK TRACE GENERATION
- call stack
- call stack
- Call stack
- call stack
- call stack
- call stack
- call stack
- linux call trace
- oops call trace 解析
- python thread stack trace
- Reconstructing Stack Trace Manually
- stack trace 栈轨迹
- 17 print stack trace
- Stack Trace简介
- Stack trace堆栈轨迹
- Windows NT Stack Trace
- 软切换、硬切换,垂直切换、水平切换
- gulp 插件
- openvz simfs to ploop
- 为何学这么多技术,却做不好Coder!
- Spring集成Quartz
- CALL STACK TRACE GENERATION
- STL中的for_each()函数
- 修复 Linux 下 sogou 输入法突然奔溃无法使用
- iOS 监听键盘的弹出,收起,并且拿到键盘的高度
- java设计模式总结
- Spring jdbcTemplate 获取insert后主键自增的表的主键id
- Python学习笔记【六】——《python基础教程》:: 抽象
- 面向对象设计的 10 条戒律
- 出现XML 文档结构必须从头至尾包含在同一个实体内的报错