交叉编译生成的可执行文件必须部署到目标机（如ARM64开发板）才能运行，因架构不兼容无法在x86_64宿主机执行；需确保带-g调试信息、ABI匹配、动态库可用，并通过scp传输、chmod赋权、gdbserver远程调试验证正确性。
交叉编译生成的可执行文件不能直接在宿主机（x86_64）上运行，必须传到目标机（如 ARM64 开发板）才能执行。远程运行测试的关键不是“怎么传”，而是“传完之后怎么确保它真能跑、跑得对、出错能查”。
确认交叉编译时带 -g 和目标平台 ABI 兼容
远程运行前若没加调试信息或 ABI 不匹配，后续连 gdbserver 都起不来，更别说观察行为。
-
-g必须显式加在编译命令里，例如：aarch64-none-linux-gnu-gcc -g hello.c -o hello；只靠 Makefile 默认规则或 IDE 隐式设置容易漏掉 - 检查目标机架构：用
uname -m确认是aarch64还是armv7l，对应选aarch64-none-linux-gnu-gcc或arm-linux-gnueabihf-gcc；混用会导致cannot execute binary file: Exec format error - 避免静态链接缺失：如果程序依赖
libstdc++.so或libpthread.so，而目标机没装对应版本，会报./hello: error while loading shared libraries；临时解决可用-static编译，但会增大体积且无法调试动态库调用
用 scp 传文件 + chmod +x 是最简路径
别绕弯用 FTP 或共享文件夹——权限和换行符问题多，scp 直接、可靠、一次到位。
- 命令示例：
scp hello root@192.168.1.100:/tmp/（假设目标机 IP 是 192.168.1.100） - 传完立刻登录目标机：
ssh root@192.168.1.100，然后执行：chmod +x /tmp/hello && /tmp/hello - 如果提示
Permission denied，不是文件没传成功，而是目标机/tmp所在分区挂载时用了noexec选项；换路径如/home/root/或重新挂载
gdbserver 启动失败常见原因和验证方式
远程调试的前提是 gdbserver 能起来。它不报错 ≠ 能用，得看它是否监听成功、端口是否通、是否被防火墙拦截。
- 启动命令必须带
--once或后台运行：gdbserver :2345 /tmp/hello；不加端口号或写成localhost:2345会导致 gdb 主机连不上 - 验证监听：
netstat -tuln | grep 2345，应看到LISTEN状态；若无输出，说明gdbserver已退出（常见于缺少动态库或架构不匹配） - 宿主机用
telnet 192.168.1.100 2345测试端口连通性；不通就查目标机iptables或ufw是否放行该端口 -
gdbserver版本需与宿主机aarch64-none-linux-gnu-gdb匹配；Ubuntu 官方源装的gdbserver常为 x86_64 版，必须用交叉工具链配套的版本（如 Buildroot 或 Linaro 提供的）
运行时权限和环境变量容易被忽略
程序在宿主机编译、在目标机运行，两者的环境差异比想象中大得多。一个看似正常的 printf 可能因 stdio 缓冲策略不同而卡住，或因 LD_LIBRARY_PATH 缺失导致段错误。
- 目标机执行前先清空干扰：
unset LD_PRELOAD && export LD_LIBRARY_PATH="/lib:/usr/lib"（根据实际路径调整） - 若程序依赖特定 locale（比如中文输出），目标机可能没装
locales包，运行时报locale not supported；临时方案是加LANG=C ./hello - 开发板常禁用
ptrace权限，导致gdbserver无法 attach 进程；检查/proc/sys/kernel/yama/ptrace_scope，值为1时需临时设为0：echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
真正卡住的点往往不在编译命令本身，而在目标机那几行 ssh 登录后的简单操作里——chmod 没加、gdbserver 监听地址写错、LD_LIBRARY_PATH 指向了不存在的目录。这些细节不试一遍，光看文档永远不确定能不能跑通。
