为了在运行时捕获诸如分段错误之类的致命错误，我编写了一个自定义 SignalHandler，它将打印堆栈跟踪到控制台并打印到日志文件中。
为了实现这一目标，我将backtrace()和backtrace_symbols()函数与 . 结合使用（在我之前有数百个） addr2line。
调用会backtrace_symbols()产生以下输出：
Obtained 8 stack frames.
./Mainboard_Software(+0xb1af5) [0x56184991baf5]
./Mainboard_Software(+0xb1a79) [0x56184991ba79]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12dd0) [0x7fe72948bdd0]
./Mainboard_Software(causeSIGFPE+0x16) [0x561849918a10]
./Mainboard_Software(_Z13MainboardInit7QString+0xf3) [0x56184990e0df]
./Mainboard_Software(main+0x386) [0x5618499182a3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fe727fd909b]
./Mainboard_Software(_start+0x2a) [0x5618498ff0aa]
我需要将偏移量传递给 addr2line 来获取我的模块名称和行号。
$ addr2line -C -a -s -f -p -e ./D098_Mainboard_Software 0xb1a79
0x00000000000b1a79: HandleBacktraceSignals at SignalModule.c:492
但是，在某些模块（尤其是 cpp 模块）中，我将偏移量作为符号和十六进制的组合获得，例如_Z13MainboardInit7QString+0xf3
我可以通过调用将符号解析为十六进制nm：
$ nm Mainboard_Software | grep _Z13MainboardInit7QString
00000000000a3fec T _Z13MainboardInit7QString
现在我可以添加这两个十六进制数字，将它们传递给 addr2line 并获取我的模块名称和行号，如果我愿意，甚至可以进行分解：
$ addr2line -C -a -s -f -p -e ./D098_Mainboard_Software 0xa40df …对于一个较大的项目，我开始了一个小项目来编写一个模块，该模块可以在 stderr 上打印堆栈跟踪。我可以捕获异常（信号）并查看堆栈，但是，当我使用 addr2line 时，我的函数只打印 ??:0。我读到您需要使用 -g 编译程序才能获取调试信息。目前，我总是使用 -g3 进行编译，因此应包含所有调试信息（对吗？）。由于 gdb 也需要调试信息，所以我测试了我的小程序，并且可以正确回溯我的信号。函数名称、行号，一切都正常。我还知道不同的包含不会有输出，因为它们没有使用 -g 标志进行编译。
这是我的代码：
造成灾难的源代码和异常处理（set_signal_handler）：
#include <stdio.h>
#include <signal.h>
#include <assert.h>
#include <stdbool.h>
#include "Backtrace.h"
int
divide_by_zero();
void
cause_segfault();
void
stack_overflow();
void
infinite_loop();
void
illegal_instruction();
void
cause_calamity();
int main(int argc, char * argv[])
{
(void) argc;
set_signal_handler();
cause_calamity();
puts("OMG! Nothing bad happend!");
return 0;
}
void cause_calamity()
{
/* uncomment one of the following error conditions to cause a calamity of
your choosing! */
// (void)divide_by_zero();
cause_segfault();
// assert(false); …I am trying to create a dynamic plotter in SDL2 for an embedded project. Currently, the code executes on both architectures, x86, and ARM. On x86 I get a smooth running plotter, however, on ARM it runs very slow at a fraction of the frames I get on x86. I am pretty sure this is because I rerender every pixel on the surface at this is a massive overheat on the embedded device.
I tried rendering the new content to …
这是我的第一个问题,如果我错过重要规则,请随意批评或纠正我.
最近我的任务是将旧的DOS C代码移植到Linux平台上.字体处理由bitfonts实现.我编写了一个函数,如果你将正确的Unicode值传递给它,它能够绘制选定的字形.
但是,如果我尝试将char转换为USHORT(函数需要此类型),当字符在ASCII表之外时,我得到错误的值.
char* test;
test = "°";
printf("test: %hu\n",(USHORT)test[0]);
显示的数字(控制台)应为176,而不是194.
如果你使用"!" 将显示正确的值33.我通过设置GCC编译器标志确保char是无符号的
-unsigned-char
GCC编译器使用UTF-8编码作为默认编码.我真的不知道现在的问题在哪里.
我是否需要在编译器中添加另一个标志？
更新
在@Kninnug回答的帮助下,我设法编写了一个能够为我生成所需结果的代码.
#include <stdio.h>
#include <locale.h>
#include <string.h>
#include <wchar.h>
#include <stdint.h>
int main(void)
{
size_t n = 0, x = 0;
setlocale(LC_CTYPE, "en_US.utf8");
mbstate_t state = {0};
char in[] = "!°?"; // or u8"zß?"
size_t in_sz = sizeof(in) / sizeof (*in);
printf("Processing %zu UTF-8 code units: [ ", in_sz);
for(n = 0; n < in_sz; ++n)
{
printf("%#x ", (unsigned char)in[n]);
} …