QEMU模拟AArch64时pthread_mutex_init失败及调试问题求助

一、查看pthread_mutex_init失败的错误信息 #

注意：pthread系列函数不会设置errno，而是直接返回错误码，可通过以下两种方式获取：

• 修改代码打印返回值：如果能编辑myProcess源码，在调用后直接打印返回码：

  #include <stdio.h>
  #include <pthread.h>
  
  // ... 原有代码 ...
  pthread_mutex_t mutex;
  int ret = pthread_mutex_init(&mutex, NULL);
  if (ret != 0) {
      printf("pthread_mutex_init failed, error code: %d\n", ret);
  }
  

  编译后重新运行，对照pthread文档即可定位原因（比如EINVAL表示参数无效，ENOMEM表示内存不足）。
• 用strace追踪系统调用：无需修改代码，在chroot环境中捕获所有系统调用及错误：

  chroot . ./qemu-aarch64-static strace ./myProcess
  

  输出中会找到pthread_mutex_init对应的调用记录，直接显示错误码和上下文信息。

二、修复gdb-multiarch无法断在main的问题 #

你的调试流程未触发断点，大概率是进程在main执行前就异常，或调试配置有误，可按以下步骤修复：

• 检查动态库加载状态：先确认所有依赖库都已正确加载，开启动态库调试日志：

  chroot . ./qemu-aarch64-static LD_DEBUG=libs ./myProcess
  

  若输出出现cannot open shared object file，说明还有依赖库未复制完整，补全后再尝试调试。
• 调整断点到程序入口_start：程序的真正启动入口是_start，main是被_start调用的，修改gdb操作步骤：

  # gdb-multiarch中执行
  file myProcess
  set architecture aarch64
  target remote 127.0.0.1:1234
  b _start  # 先断在程序入口
  c
  # 程序停在_start后，再设置main断点
  b main
  c
  

• 配置gdb动态库搜索路径：如果chroot环境的库路径与主机不同，需在gdb中指定符号搜索路径：

  # 替换为你的chroot目录绝对路径
  set solib-search-path /path/to/your/chroot/dir
  info sharedlibrary  # 确认目标程序和依赖库的符号已加载
  

• 调整QEMU启动参数：添加-singlestep强制单步启动，便于调试初期定位问题：

  chroot . ./qemu-aarch64-static -g 1234 -singlestep ./myProcess
  

内容的提问来源于stack exchange，提问作者python3.789