ldd查的是可执行文件静态声明的依赖，pldd查的是进程运行时实际加载的共享库；ldd仅解析elf的dt_needed条目且不接触进程内存，无法反映dlopen、ld_preload等动态行为，而pldd通过读取/proc/pid/maps直接获取运行时真实映射，需root权限。
直接说结论： ldd 查的是「可执行文件静态声明的依赖」，pldd 查的是「进程运行时实际加载的共享库」——两者根本不是一回事，不能互相替代。
为什么 ldd 不能用来查正在运行的进程？
ldd 本质是解析 ELF 文件的 DT_NEEDED 条目，再模拟动态链接器加载行为。它根本不接触进程内存，只读磁盘上的二进制文件。
- 对已启动的进程，
ldd /proc/1234/exe看到的仍是该程序**编译时声明的依赖**，不是它此刻真正用到的库（比如 dlopen 动态加载的） - 如果进程用了
LD_PRELOAD、自定义rtld或修改了ld.so.cache，ldd完全无法反映 - 更严重的是：
ldd在某些旧版 glibc 中会真实执行目标程序的初始化代码，对不可信二进制有安全风险
pldd 是什么，为什么必须用 root 运行？
pldd 直接读取 /proc/<pid>/maps</pid> 和 /proc/<pid>/mem</pid>，从中提取当前进程地址空间里所有被 mmap 的 .so 文件路径。这属于内核暴露的运行时状态。
- 必须
sudo pldd <pid></pid>，因为普通用户无权读取/proc/<pid>/mem</pid> - 输出里能看到
libpython3.10.so.1.0这类由import触发加载的库，ldd永远列不出来 - 若进程已崩溃或处于
T（stopped）状态，pldd可能失败并报Operation not permitted
实际排查时怎么选：ldd 还是 pldd？
看你要解决的问题类型：
- 程序启动就报
error while loading shared libraries: libxxx.so: cannot open shared object file→ 用ldd ./myapp | grep "not found" - 程序能启动但运行中突然 segfault，怀疑某库版本不匹配或被覆盖 → 用
sudo pldd <pid> | grep libxxx</pid>确认实际加载的是哪个路径 - 想验证
LD_LIBRARY_PATH是否生效 →pldd输出里会出现你指定路径下的库；ldd不受运行时环境变量影响 - 检查是否真有 dlopen 行为 →
pldd会列出那些没出现在ldd结果里的库，比如libcuda.so.1（CUDA 应用常见）
安全替代方案：不用 ldd 也能看静态依赖
当面对来源不明的二进制，又需要确认它声明了哪些库时，避免 ldd 的执行风险：
-
readelf -d ./malware.bin | grep NEEDED—— 最轻量，只解析 ELF 动态段 -
objdump -p ./malware.bin | grep NEEDED—— 输出格式稍不同，但等价 - 注意：这两个命令都**不会触发任何代码执行**，也不依赖 glibc 版本
真正容易被忽略的点是：pldd 看到的库路径可能来自 /proc/<pid>/maps</pid> 的 pathname 字段，而这个字段在内核中可能为空（比如匿名 mmap 或被 unlink 的 so），此时 pldd 就显示 [anon] —— 这种情况只能结合 strace -e trace=openat,openat64 -p <pid></pid> 追踪实际打开行为。
