嵌入式开发中必须使用交叉编译器（如arm-none-eabi-gcc）、分步编译（-c）、指定链接脚本（-T）、链接必要库（-lc -lgcc）、命令行预处理控制（-D/-I/-include）及合理搭配-g与优化选项，缺一不可。
嵌入式开发中用 GCC，不是直接敲 gcc 就完事——目标平台（比如 ARM Cortex-M）、运行环境（bare-metal 还是 Linux）、资源约束（Flash/RAM 有限）全都会倒逼你改命令。关键不在于“有哪些”，而在于“哪些必须改、哪些不能省”。
交叉编译器名字不能硬写 gcc
你在 Ubuntu 上编译 STM32 程序，gcc 默认生成 x86_64 可执行文件，根本跑不起来。必须用交叉工具链：
-
arm-none-eabi-gcc：裸机 ARM Cortex-M（STM32、NXP Kinetis）最常用 -
riscv-none-elf-gcc：RISC-V 架构（GD32V、ESP32-C3） -
arm-buildroot-linux-gnueabihf-gcc：ARM Linux 应用（如 IMX6ULL 上跑的用户态程序）
错误做法：gcc -mcpu=cortex-m4 main.c —— 即使加了 -mcpu，链接时仍会找 host 的 libc 和 crt0，必然报错 undefined reference to `__libc_init_array' 或 cannot find -lc。
-c 和 -o 是多文件工程的底线操作
一个实际项目总有 main.c、uart.c、gpio.c，你不可能每次改一个文件就全量重编。必须分步：
arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -O2 main.c -o main.oarm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -O2 uart.c -o uart.oarm-none-eabi-gcc -T stm32f407vg.ld -o firmware.elf main.o uart.o -lc -lgcc
注意三点：
-
-c必须出现，否则会尝试链接，而单个 .c 文件没入口也没库，直接失败 -
-T指定链接脚本（.ld），没它，代码可能被塞进 Flash 末尾或 RAM 乱地址，烧录后复位就飞 -
-lc和-lgcc不是可选——裸机环境下，printf、memcpy、甚至__aeabi_uidiv都得靠它们提供，漏掉就undefined reference
-D、-I、-include 控制预处理，比写 #ifdef 更可靠
嵌入式项目常需条件编译（比如 DEBUG 模式开串口日志、量产版关掉），但靠源码里手动改 #define DEBUG 容易漏、难维护。统一用命令行控制：
-
-DDEBUG：等价于在所有 .c 文件开头插一句#define DEBUG -
-DSTM32F407xx：HAL 库依赖这个宏识别芯片型号，不加编译不过 -
-I./inc -I./Drivers/STM32F4xx_HAL_Driver/Inc：头文件路径必须显式给出，HAL 库的stm32f4xx_hal.h不在默认搜索路径里 -
-include config.h：比在每个 .c 里写#include "config.h"更安全——哪怕某个 .c 忘了包含，也能保证配置生效
常见坑：-I 路径末尾别加 /（-I./inc/ 是错的），GCC 会把它当绝对路径处理，导致找不到头文件。
-g 和优化选项必须配合，否则调试等于盲人摸象
裸机调试用 OpenOCD + GDB，如果编译没带 -g，GDB 里看不到变量、跳不到行号、step 直接跳函数外——因为符号表根本没生成。
-
-g：基础调试信息，够用 -
-g3：带宏定义展开信息，查#define BAUDRATE 115200实际值时有用 -
-O0：调试阶段首选，关优化，变量生命周期和源码严格对应 -
-Os：发布前必用，嵌入式 Flash 紧张，-Os比-O2更省空间，且不牺牲太多性能
致命组合：-O2 -g —— 编译器重排指令、内联函数、删临时变量，GDB 显示的“当前行”可能和真实执行顺序差好几行，尤其在中断服务函数里，极易误判。
真正卡住人的从来不是记不住命令，而是没意识到：交叉工具链名、链接脚本、库依赖、预处理控制、调试与优化的取舍——这五件事一旦漏掉任一环，编译通过但板子不跑，或者跑起来但没法调，问题就藏在这些看似琐碎的参数里。
