pldd是唯一能直接反映进程当前实际加载共享库的命令，它通过读取/proc/pid/maps和/proc/pid/mem提取r-xp且含.so的内存段，可捕获dlopen、ld_preload、import等动态加载的库，需root权限；ldd仅解析elf静态依赖，对运行中进程完全无效。
pldd 是唯一能直接反映进程当前实际加载了哪些共享库的命令，其他工具如 ldd、lsof、pmap 都只能间接推断或存在严重盲区。
pldd 查运行中进程真实加载的 .so
pldd 直接读取 /proc/<pid>/maps</pid> 和 /proc/<pid>/mem</pid>，提取所有被 mmap 为可执行（r-xp）且路径含 .so 的内存段。它能看到 dlopen() 加载的库、LD_PRELOAD 注入的库、Python import 触发的 libpython3.x.so，这些 ldd 完全看不到。
- 必须用 root 权限：普通用户执行会报
Operation not permitted - 示例：
sudo pldd 1234或sudo pldd $(pidof nginx) - 输出里每行都是一个真实映射的
.so路径，比如/usr/lib/x86_64-linux-gnu/libcuda.so.1 - 若进程处于
T（stopped）或已崩溃状态，pldd可能失败——这不是权限问题，是内核拒绝访问其内存
ldd 只查静态声明，对运行中进程完全无效
ldd 不读进程内存，只解析 ELF 文件的 DT_NEEDED 条目，本质是模拟链接器加载行为。它连 /proc/1234/exe 都只是当成普通文件处理，输出的是编译时写死的依赖。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
ldd 1234会报not a dynamic executable—— 因为 1234 是数字，不是 ELF 文件 -
ldd /proc/1234/exe看到的仍是原始二进制声明的库，不是进程此刻加载的 - 它无法反映
LD_LIBRARY_PATH、RUNPATH、ldconfig缓存的影响 - 某些旧版 glibc 中，
ldd甚至会执行目标程序的初始化代码，有安全风险
替代方案：轻量但有漏判，适合无 root 场景
当无法使用 sudo pldd 时，可用以下方式快速查看部分已映射的 .so，但注意局限性：
cat /proc/1234/maps | grep '.so' | awk '{print $6}' | sort -u
优点：无需 root；缺点：漏掉无路径的 memfd 库（如某些容器或 eBPF 工具加载的匿名.so）pmap 1234 | grep '.so' | awk '{print $4}' | sort -u
优点：格式清晰；缺点：不显示完整路径，有时只显示 basenamelsof -p 1234 | awk '$4 ~ /.so$/ {print $9}' | sort -u
优点：语义直观；缺点：依赖lsof权限配置，且可能把符号链接和硬链接重复计数
这些方法都绕不开同一个事实：它们靠的是文件描述符或内存映射快照，而真正动态加载、又未持久化到文件系统的库，只有 pldd 能稳定捕获。
真正麻烦的从来不是“有没有加载”，而是“加载的是哪个路径下的同名库”——pldd 输出的完整绝对路径，才是你排查版本冲突、LD_PRELOAD 覆盖、容器挂载覆盖等问题时不可替代的一手依据。
