写代码的时候，谁还没遇到过几个bug？打开gdb准备一步步排查，结果一运行就报错：‘无法加载可执行文件’或者‘No such file or directory’。这时候别急着翻手册，先想想：你的程序真的编译成功了吗？
调试的前提是有个能跑的程序
gdb是调试工具，不是编译修复器。它只能调试已经生成的可执行文件。如果源码还没通过编译，压根就没有可执行程序，gdb自然无从下手。就像修车前得先有辆车，不能对着一堆零件开始拧扳手。
常见的情况是，你改了几行代码，心急火燎地敲下 gdb ./myapp，结果系统提示文件不存在。一查目录，确实没有这个文件——因为上次编译就失败了，你还浑然不知。
编译失败的信号别忽略
每次编译后，注意观察终端输出。哪怕只有一条警告或错误，都可能意味着生成失败。比如：
gcc -g -o myapp main.c
main.c: In function ‘main’:
main.c:5:10: error: expected ‘;’ before ‘return’
return 0
^
这种情况下，myapp根本不会被生成，但有些人习惯性按上箭头重新运行gdb，结果当然是徒劳。养成习惯：每次编译后确认没有error，再进入调试阶段。
加-g参数只是第一步
为了调试方便，记得在编译时加上 -g 参数，这样才能在gdb里看到变量名、源码行号等信息。但前提是编译得成功。正确的命令应该是：
gcc -g -Wall -o myapp main.c只有这条命令安静地执行完，没报错，才能接着运行：
gdb ./myapp一个小脚本帮你避坑
如果你经常在编译和调试之间切换，可以写个简单的shell脚本防呆：
#!/bin/bash
gcc -g -Wall -o myapp main.c && gdb ./myapp这样，只有编译通过了，gdb才会启动。编译失败，整个命令就停下来，省得你在无效操作上浪费时间。
调试是解决问题的手段，但前提是问题出在逻辑上，而不是连程序都没跑起来。每次开gdb前，停半秒问问自己：我编译成功了吗？这一步花不了你一秒钟，却能避免几十分钟的困惑。