1 前言在软件开发的过程中我们不仅需要实现业务功能还常常需要深入底层进行问题定位。在常规的 UNIX-like 系统上常用的问题定位手段有这几类进程跟踪。业界有很多知名的用于进程跟踪的开源工具它们实现的功能各不相同但归根结底都是跟踪某个进程的运行过程大多都是依赖操作系统提供的 ptrace syscall 去实现这个能力。典型的工具有 gdb、lldb、strace、ltrace 等。系统日志。每个操作系统都有日志机制。比如 Linux 上面会有各种各样的日志包括 systemd 服务日志、内核日志等。proc 文件系统。通过读 proc 文件系统我们可以观测到进程运行过程中的各种状态。内核打点。ftrace 和 eBPF 都是常用的内核打点机制这需要操作系统内核支持。受限于当前鸿蒙 PC 的安全管控措施上述大多数手段在鸿蒙 PC 上并不可用本文档仅整理出当前可用的部分。2 进程跟踪2.1 lldb在当前 6.1 版本的 HarmonyOS 系统中自签名二进制无法拥有 ptrace 权限因此我们自己编译的 lldb 是无法正常工作的必须要使用 ohos-sdk 里面提供的 lldb并且版本要足够新。为什么需要新版本OpenHarmony 社区在最新版本的 ohos-sdk 中对 lldb 做了证书签名而非自签名证书签名可以让二进制拥有更多高级权限ptrace 就包括在内。我们可以去 OpenHarmony 的日构建流水线下载最新的 ohos-sdk-full_ohos 制品curl-fL-oohos-sdk-full_ohos.tar.gz https://cidownload.openharmony.cn/version/Daily_Version/ohos-sdk-full_ohos/20260728_020506/version-Daily_Version-ohos-sdk-full_ohos-20260728_020506-ohos-sdk-full_ohos.tar.gztar-zxfohos-sdk-full_ohos.tar.gz-C~/rm~/daily_build.log ~/manifest_tag.xmlcd~/ohos-sdk/ohosunzip-uqnative-*.zipcd-现在你可以在 ohos-sdk 中找到 lldb 程序路径是~/ohos-sdk/ohos/native/llvm/bin/lldb。这个 lldb 在鸿蒙 PC 上可正常工作。附赠一个技巧如何检查你下载的 lldb 文件是否具有调试权限。方法非常简单使用 binary-sign-tool 查看签名信息即可该工具来自 ohos-sdkbinary-sign-tool display-sign-inFile~/ohos-sdk/ohos/native/llvm/bin/lldb如果你的 lldb 是具有调试权限的版本你将会得到这样的信息07-29 10:37:12.321 INFO - permission { requestPermissions: [{ name: ohos.permission.kernel.ALLOW_DEBUG }, { name: ohos.permission.kernel.DEBUGGER }, { name: ohos.permission.READ_WRITE_USB_FILE }], version: 1 } 07-29 10:37:12.333 INFO - certificate #0 Version: 3 (0x2) Serial Number: 09:fc:0d:1c:17:b5:b3:b1:19:91:67:ec:90:16 Signature Algorithm: ecdsa-with-SHA384 Issuer: CCN,OHuawei,OUHuawei CBG,CNHuawei CBG Developer Relations CA G2 Validity Not Before: Nov 24 06:53:47 2025 GMT Not After : Nov 24 06:53:47 2028 GMT Subject: CCN,O\U5F00\U653E\U539F\U5B50\U5F00\U6E90\U57FA\U91D1\U4F1A,OU1826159925408081473,CN\U5F00\U653E\U539F\U5B50\U5F00\U6E90\U57FA\U91D1\U4F1A(1826159925408081473)\,DevID查询结果显示这个文件拥有ohos.permission.kernel.ALLOW_DEBUG和ohos.permission.kernel.DEBUGGER权限并且下方展示了证书链。证书链里面显示颁发者是华为可能是应用市场或者开发者中心之类的网站颁发的证书的所属主体属于开放原子基金会。那一串 Unicode 转义序列解码出来是“开放原子基金会”几个字。2.2 QEMU在当前 6.1 版本的 HarmonyOS 系统中自签名二进制无法拥有 ptrace 权限我们自己编译的 strace 是无法正常工作的。好在 QEMU 也提供了与 strace 类似的功能。并且这个功能是在纯用户态实现的不需要内核 ptrace 权限。因此我们可以用 QEMU 来作为 strace 的替代品。由于 QEMU 的构建过程十分繁琐我这里选择直接从 Alpine Linux 的软件源里面下载构建好的版本。这个版本静态链接了 musl libc在鸿蒙 PC 上也可正常使用。# 准备一个安装目录这里以家目录为例mkdir~/qemu-aarch64# 从 Alpine Linux 软件源下载 qemu-aarch64# 由于 apk 文件的下载链接随时可能过期这里选择从包索引文件里面实时解析出最新的下载链接package_nameqemu-aarch64alpine_repositoryhttps://mirrors.huaweicloud.com/alpine/v3.24/community/aarch64curl-fsSL${alpine_repository}/APKINDEX.tar.gz|tar-zx-C~/qemu-aarch64package_version$(grep-A1^P:${package_name}$~/qemu-aarch64/APKINDEX|sed-ns/^V://p)apk_file_name${package_name}-${package_version}.apkcurl-L-O${alpine_repository}/${apk_file_name}tar-zxf${apk_file_name}-C~/qemu-aarch64# 需进行代码签名后使用签名工具来自 ohos-sdkcd~/qemu-aarch64/usr/bin binary-sign-tool sign-selfSign1-inFileqemu-aarch64-outFileqemu-aarch64cd-现在你得到了一个可用的 qemu-aarch64 可执行文件文件位于~/qemu-aarch64/usr/bin/qemu-aarch64。我们尝试用它来作为 ELF 解释器用来执行一个程序# 解释 ELF 文件的时候需要输入文件路径# 执行过程中加上 -strace 参数输出系统调用日志~/qemu-aarch64/usr/bin/qemu-aarch64-strace/bin/ls你将会得到这样的日志输出格式与 strace 工具一模一样38114set_tid_address(0x7e1fa611e8)3811438114mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0)0x0000007e1efa700038114madvise(0x0000007e1efa7000,4096,MADV_DONTNEED)038114munmap(0x0000007e1efa7000,4096)038114mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0)0x0000007e1efa700038114prctl(1398164801,0,541685608448,4096,541694890400,541694890400)-1errno22(Invalid argument)38114madvise(0x0000007e1efa7000,4096,MADV_FREE)038114munmap(0x0000007e1efa7000,4096)0...最后需要澄清一个常见误区使用了 QEMU并不等于运行在虚拟机中。这里使用的只是 QEMU 用户态解释器并没有虚拟出完整的硬件设备和操作系统。程序发起的 syscall 最终仍会下发给鸿蒙内核因此不会改变程序原有的运行逻辑。由于这些 syscall 在下发内核前会先由 QEMU 进行拦截与转发我们得以轻松捕捉并观测它们。3 系统日志对底层开发而言定位问题最有价值的日志就是内核日志了。要查看内核日志大家可能会首先想到 dmesg 命令和 /dev/kmsg 文件。在鸿蒙 PC 上dmesg 命令和 /dev/kmsg 文件都是存在的但它们并不向用户开放因此我们无法通过这两个途径查看内核日志。要查看内核日志唯一的途径就是 HiLog。HiLog 日志系统除了会收集应用日志外还会收集内核日志并且这部分日志是向用户开放的。只需要在 HiShell 中执行这句命令就能看到有内核日志源源不断打出hilog-tkmsg一般情况下使用自己的进程名字作为过滤关键字就能知道你的程序被什么安全模块拦截了hilog-tkmsg|grepmy_program你也可以使用安全模块的名字来作为过滤关键字例如avc、xpm、hmsecpt都是引发拦截的常见模块hilog-tkmsg|grep-Eavc|xpm|hmsecpt关于这几个日志的作用这里提供一些个人经验总结由于缺乏官方资料暂无权威信息avc: 程序被 selinux 拦截会产生这方面的日志xpm: 程序因代码签名无效而验签不通过会产生这方面的日志hmsecpt程序被 seccomp 拦截会产生这方面的日志4 proc 文件系统proc 文件系统涉及范围太广这里不展开介绍只说一个大致结论在鸿蒙 PC 上/proc下的部分路径是向用户开放的尤其是/proc/self下面的节点几乎是完全开放的。用户需要使用哪个路径可以自行尝试访问。