交叉编译时 Boost stacktrace 不 demangling 名称
Boost stacktrace not demangling names when cross compiled
为了生成堆栈跟踪,我正在使用 boost::stacktrace
。我在 Debian 上有一个构建代理,它正在编译一个 unix 和一个 windows 版本的程序。 Unix 版本是使用安装的本机 g++
编译的,windows 交叉编译是使用 mingw-w64
创建的。我正在为两个编译使用 libbacktrace
后端。 boost 和 libbacktrace 本身都是使用相同的 mingw-w64 编译器在 Debian 机器上编译的。
在我的 CMakeLists.txt
中,我指定:add_definitions(-DBOOST_STACKTRACE_USE_BACKTRACE)
堆栈跟踪是这样生成的:
namespace foo {
class Bar {
public:
void fooBar() {
std::cout << boost::stacktrace::stacktrace() << std::endl;
}
};
}
int main(int argc, char *argv[]) {
foo::Bar bar;
bar.fooBar();
}
当在我的计算机上编译时(基本 OS)以及从我的 unix 机器上的构建服务器下载时,这会产生以下输出(使用 -g 并且没有优化)。
0# foo::Bar::fooBar() in /home/cromon/CLionProjects/test-proj/cmake-build-debug/test-proj
1# main at /home/cromon/CLionProjects/test-proj/main.cpp:31
2# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
3# _start in /home/cromon/CLionProjects/test-proj/cmake-build-debug/test-proj
这是在我的 unix 机器上的构建服务器上创建的二进制文件的输出:
0# foo::Bar::fooBar() in ./test-proj
1# main at /opt/teamcity/2018.2/TeamCity/buildAgent/work/d79789e141c5605f/test-proj/main.cpp:31
2# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
3# _start in ./test-proj
现在,如果我在我的 Windows 机器上使用在 Unix 上使用 mingw 编译的二进制文件,可以观察到以下输出
0# ZN5boost10stacktrace16basic_stacktraceISaINS0_5frameEEE4initEyy at /opt/teamcity/boost/1_69/windows/include/boost-1_69/boost/stacktrace/stacktrace.hpp:75
1# ZN3foo3Bar6fooBarEv at /opt/teamcity/2018.2/TeamCity/buildAgent/work/eb975d0a928ba129/test_proj/main.cpp:22
2# main at /opt/teamcity/2018.2/TeamCity/buildAgent/work/eb975d0a928ba129/test_proj/main.cpp:31
3# _tmainCRTStartup at ./mingw-w64-crt/crt/crtexe.c:336
4# mainCRTStartup at ./mingw-w64-crt/crt/crtexe.c:214
5# register_frame_ctor in C:\WINDOWS\System32\KERNEL32.DLL
6# register_frame_ctor in C:\WINDOWS\SYSTEM32\ntdll.dll
我也曾尝试循环遍历帧并在它们上 运行 一个 boost::core::demangle
,但它失败了。
到目前为止,我在 unix 上的编译环境和我的 windows 机器上的 运行time 环境之间只有一个区别。在 Windows 上,我有 g++
版本 8.2.0
,在 unix 上它是 6.3.0
。这会导致任何问题吗?当交叉编译时,还有什么可能导致 demangling 仅在 windows 上失败?
TL/DR:libbacktrace 出于某种原因去除了前导下划线并错误地调用了 boost backtrace_pcinfo
-> 将创建 libbacktrace 和 boost 的问题(已在我的本地编译中修复)
更详细的回复:
我能够通过创建 libbacktrace 的调试版本并单步执行代码来找出奇怪的行为。在我看来,boost 和 libbacktrace 中都有一个错误。
非常高级的解释 boost::stacktrace 在选择 libbacktrace 后端时如何工作:
- 调用
backtrace_pcinfo
,这将读取(在第一次调用时)并搜索 DWARF 调试信息(至少是 mingw 实现)
- 如果之前的调用成功,它会 return 在这里,因为它已经获得了足够多的信息(函数、文件、行)
- 如果它 return 为零,它将尝试调用
backtrace_syminfo
。这将(对于 mingw)搜索 coff 符号 table
- 如果它 return 为零,您将打印原始地址,否则至少打印函数名称(无 file/line)
我能够追溯到 libbacktrace(双关语)的第一个 bug/unexpected 行为。 gcc/pecoff.c#440 中的实现出于某种原因去除了前导下划线(如果存在)。这就是函数名称都缺少前导下划线并且无法被分解的原因。我认为这可以被认为是一个错误,或者至少除了尝试漂亮的打印符号失败之外我没有看到任何其他原因。
现在细心的reader大概记得我的问题是我用的是调试信息,所以应该不需要进入coff符号table而是应该使用DWARF调试信息。这就是boost的bug所在。
backtrace_pcinfo
必须用两个回调调用。第一个将接收已解析的符号信息(如果有),第二个是错误回调。当找到一个交易品种时,第一个回调被调用,其 return 值是 return 从 backtrace_pcinfo
或代码中编辑:
return 共 backtrace_pcinfo
:return state->fileline_fn (state, pc, callback, error_callback, data);
fileline_fn
for mingw 是 dwarf 实现 dwarf_fileline
,return 是这样的:
ret = dwarf_lookup_pc (state, ddata, pc, callback, error_callback,
data, &found);
if (ret != 0 || found)
return ret;
dwarf_lookup_pc
现在 return 找到符号时回调 return 的内容:return callback (data, pc, filename, lineno, function->name);
现在让我们看看回调看起来如何提供 boost:
inline int libbacktrace_full_callback(void *data, uintptr_t /*pc*/, const char *filename, int lineno, const char *function) {
pc_data& d = *static_cast<pc_data*>(data);
if (d.filename && filename) {
*d.filename = filename;
}
if (d.function && function) {
*d.function = function;
}
d.line = lineno;
return 0;
}
由于 return 值直接传播到 backtrace_pcinfo
这意味着无论是否找到任何内容,此检查将始终进入 or
情况:
::backtrace_pcinfo(
state,
reinterpret_cast<uintptr_t>(addr),
boost::stacktrace::detail::libbacktrace_full_callback,
boost::stacktrace::detail::libbacktrace_error_callback,
&data
)
||
::backtrace_syminfo(
state,
reinterpret_cast<uintptr_t>(addr),
boost::stacktrace::detail::libbacktrace_syminfo_callback,
boost::stacktrace::detail::libbacktrace_error_callback,
&data
);
这意味着它将始终使用以某种方式去除前导 space 的实现。我将回调更改为 return 1
现在一切正常。
为了生成堆栈跟踪,我正在使用 boost::stacktrace
。我在 Debian 上有一个构建代理,它正在编译一个 unix 和一个 windows 版本的程序。 Unix 版本是使用安装的本机 g++
编译的,windows 交叉编译是使用 mingw-w64
创建的。我正在为两个编译使用 libbacktrace
后端。 boost 和 libbacktrace 本身都是使用相同的 mingw-w64 编译器在 Debian 机器上编译的。
在我的 CMakeLists.txt
中,我指定:add_definitions(-DBOOST_STACKTRACE_USE_BACKTRACE)
堆栈跟踪是这样生成的:
namespace foo {
class Bar {
public:
void fooBar() {
std::cout << boost::stacktrace::stacktrace() << std::endl;
}
};
}
int main(int argc, char *argv[]) {
foo::Bar bar;
bar.fooBar();
}
当在我的计算机上编译时(基本 OS)以及从我的 unix 机器上的构建服务器下载时,这会产生以下输出(使用 -g 并且没有优化)。
0# foo::Bar::fooBar() in /home/cromon/CLionProjects/test-proj/cmake-build-debug/test-proj
1# main at /home/cromon/CLionProjects/test-proj/main.cpp:31
2# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
3# _start in /home/cromon/CLionProjects/test-proj/cmake-build-debug/test-proj
这是在我的 unix 机器上的构建服务器上创建的二进制文件的输出:
0# foo::Bar::fooBar() in ./test-proj
1# main at /opt/teamcity/2018.2/TeamCity/buildAgent/work/d79789e141c5605f/test-proj/main.cpp:31
2# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
3# _start in ./test-proj
现在,如果我在我的 Windows 机器上使用在 Unix 上使用 mingw 编译的二进制文件,可以观察到以下输出
0# ZN5boost10stacktrace16basic_stacktraceISaINS0_5frameEEE4initEyy at /opt/teamcity/boost/1_69/windows/include/boost-1_69/boost/stacktrace/stacktrace.hpp:75
1# ZN3foo3Bar6fooBarEv at /opt/teamcity/2018.2/TeamCity/buildAgent/work/eb975d0a928ba129/test_proj/main.cpp:22
2# main at /opt/teamcity/2018.2/TeamCity/buildAgent/work/eb975d0a928ba129/test_proj/main.cpp:31
3# _tmainCRTStartup at ./mingw-w64-crt/crt/crtexe.c:336
4# mainCRTStartup at ./mingw-w64-crt/crt/crtexe.c:214
5# register_frame_ctor in C:\WINDOWS\System32\KERNEL32.DLL
6# register_frame_ctor in C:\WINDOWS\SYSTEM32\ntdll.dll
我也曾尝试循环遍历帧并在它们上 运行 一个 boost::core::demangle
,但它失败了。
到目前为止,我在 unix 上的编译环境和我的 windows 机器上的 运行time 环境之间只有一个区别。在 Windows 上,我有 g++
版本 8.2.0
,在 unix 上它是 6.3.0
。这会导致任何问题吗?当交叉编译时,还有什么可能导致 demangling 仅在 windows 上失败?
TL/DR:libbacktrace 出于某种原因去除了前导下划线并错误地调用了 boost backtrace_pcinfo
-> 将创建 libbacktrace 和 boost 的问题(已在我的本地编译中修复)
更详细的回复:
我能够通过创建 libbacktrace 的调试版本并单步执行代码来找出奇怪的行为。在我看来,boost 和 libbacktrace 中都有一个错误。
非常高级的解释 boost::stacktrace 在选择 libbacktrace 后端时如何工作:
- 调用
backtrace_pcinfo
,这将读取(在第一次调用时)并搜索 DWARF 调试信息(至少是 mingw 实现) - 如果之前的调用成功,它会 return 在这里,因为它已经获得了足够多的信息(函数、文件、行)
- 如果它 return 为零,它将尝试调用
backtrace_syminfo
。这将(对于 mingw)搜索 coff 符号 table - 如果它 return 为零,您将打印原始地址,否则至少打印函数名称(无 file/line)
我能够追溯到 libbacktrace(双关语)的第一个 bug/unexpected 行为。 gcc/pecoff.c#440 中的实现出于某种原因去除了前导下划线(如果存在)。这就是函数名称都缺少前导下划线并且无法被分解的原因。我认为这可以被认为是一个错误,或者至少除了尝试漂亮的打印符号失败之外我没有看到任何其他原因。
现在细心的reader大概记得我的问题是我用的是调试信息,所以应该不需要进入coff符号table而是应该使用DWARF调试信息。这就是boost的bug所在。
backtrace_pcinfo
必须用两个回调调用。第一个将接收已解析的符号信息(如果有),第二个是错误回调。当找到一个交易品种时,第一个回调被调用,其 return 值是 return 从 backtrace_pcinfo
或代码中编辑:
return 共 backtrace_pcinfo
:return state->fileline_fn (state, pc, callback, error_callback, data);
fileline_fn
for mingw 是 dwarf 实现 dwarf_fileline
,return 是这样的:
ret = dwarf_lookup_pc (state, ddata, pc, callback, error_callback,
data, &found);
if (ret != 0 || found)
return ret;
dwarf_lookup_pc
现在 return 找到符号时回调 return 的内容:return callback (data, pc, filename, lineno, function->name);
现在让我们看看回调看起来如何提供 boost:
inline int libbacktrace_full_callback(void *data, uintptr_t /*pc*/, const char *filename, int lineno, const char *function) {
pc_data& d = *static_cast<pc_data*>(data);
if (d.filename && filename) {
*d.filename = filename;
}
if (d.function && function) {
*d.function = function;
}
d.line = lineno;
return 0;
}
由于 return 值直接传播到 backtrace_pcinfo
这意味着无论是否找到任何内容,此检查将始终进入 or
情况:
::backtrace_pcinfo(
state,
reinterpret_cast<uintptr_t>(addr),
boost::stacktrace::detail::libbacktrace_full_callback,
boost::stacktrace::detail::libbacktrace_error_callback,
&data
)
||
::backtrace_syminfo(
state,
reinterpret_cast<uintptr_t>(addr),
boost::stacktrace::detail::libbacktrace_syminfo_callback,
boost::stacktrace::detail::libbacktrace_error_callback,
&data
);
这意味着它将始终使用以某种方式去除前导 space 的实现。我将回调更改为 return 1
现在一切正常。