第4章 RISC-V GCC实战

第4章 RISC-V GCC实战：编译选项详解、链接脚本编写、Makefile实战

说实话，很多做嵌入式开发的朋友，拿到RISC-V工具链第一件事就是敲个gcc -o hello hello.c。能跑，但心里没底。我当年也是这样，直到有一次在项目里因为一个编译优化选项没选对，导致整个中断响应时间翻了三倍……从那以后，我养成了一个习惯：把编译选项、链接脚本、Makefile这三样东西吃透，再动手写代码。

这一章，我们就来聊聊这三件事。我会结合我自己的项目经验，把那些容易踩的坑、常用的套路，都给你捋一遍。

4.1 编译选项：不只是-O0和-O2

RISC-V GCC的编译选项，说白了就是告诉编译器：你要怎么把我的C代码变成机器码。选项很多，但常用的就那么几类。我按我的使用频率给你排个序。

4.1.1 架构与ABI选项

这是最关键的。选错了，程序跑不起来。

选项	说明	我的建议
`-march=rv32imafc`	指定指令集架构	根据芯片手册来，别想当然
`-mabi=ilp32f`	指定ABI（二进制接口）	ilp32f对应单精度浮点，ilp32d对应双精度
`-mcmodel=medany`	代码模型，影响寻址范围	小芯片用medlow，大项目用medany

我曾经踩过的坑： 有一次我把-march写成了rv32imaf，少了个c（压缩指令扩展）。结果代码体积大了30%，Flash差点装不下。后来排查了半天才发现是这里的问题。所以，一定要和芯片手册核对。

4.1.2 优化选项：性能与体积的博弈

优化选项是门艺术。我个人的经验是：

-Os：代码体积优先。适合Flash紧张的场景。我做过一个IoT项目，Flash只有64KB，不用-Os根本塞不下。
-O2：性能优先。适合计算密集型的任务。但要注意，-O2可能会改变代码的执行顺序，如果你有volatile变量或者中断服务函数，要小心。
-Og：调试优化。这个是我调试时的首选。它既保留了调试信息，又做了一些不影响调试的优化。

一个小技巧： 如果你不确定某个优化选项会不会出问题，可以先用-O0编译一个版本，再用-O2编译一个版本，对比一下反汇编代码。差异一目了然。

4.1.3 调试与警告选项

这些选项平时不起眼，关键时刻能救命。

-g：生成调试信息。这个不用多说，调试必备。
-Wall -Wextra：开启所有警告。我建议把警告当错误处理，加上-Werror。
-ffunction-sections -fdata-sections：把每个函数/数据放到独立的section。配合链接脚本的--gc-sections，可以自动剔除未使用的代码。

4.2 链接脚本：芯片的“地图”

链接脚本，说白了就是告诉链接器：你的代码该放哪，数据该放哪。没有它，编译器不知道Flash和RAM的地址范围。

我刚开始学的时候，觉得链接脚本很神秘。后来自己手写了几次，发现其实就那么几个关键点。

4.2.1 链接脚本的基本结构

一个典型的RISC-V链接脚本长这样：

OUTPUT_ARCH(riscv)
ENTRY(_start)

MEMORY
{
    flash (rx)  : ORIGIN = 0x80000000, LENGTH = 512K
    ram   (rwx) : ORIGIN = 0x80080000, LENGTH = 128K
}

SECTIONS
{
    .text : {
        *(.text.init)
        *(.text)
    } > flash

    .data : {
        *(.data)
    } > ram AT > flash

    .bss : {
        *(.bss)
    } > ram
}

这里有几个关键点：

MEMORY：定义芯片的物理内存布局。ORIGIN是起始地址，LENGTH是长度。
SECTIONS：定义各个段（.text、.data、.bss）放在哪个内存区域。
AT > flash：表示.data段的加载地址在Flash，但运行地址在RAM。启动代码需要把.data从Flash拷贝到RAM。

    我个人的习惯： 我会在链接脚本里加一个.stack段，专门放栈。这样栈的起始地址和大小一目了然，调试时也方便。

4.2.2 常见坑点

栈溢出检测：在.bss段后面留一个“哨兵”区域，初始化为0xDEADBEEF。程序运行一段时间后检查这个区域是否被改写。
中断向量表：RISC-V的中断向量表通常放在0x80000000（Flash起始地址）。记得在链接脚本里把.text.init放在最前面。
对齐问题：有些外设要求数据结构按4字节或8字节对齐。可以在链接脚本里用ALIGN(4)强制对齐。

4.3 Makefile实战：从单文件到工程管理

Makefile这东西，说白了就是“自动化编译脚本”。我见过很多新手喜欢用IDE，一键编译。但到了项目后期，需要定制编译选项、管理多个源文件时，Makefile的优势就体现出来了。

4.3.1 一个最小可用的Makefile

CROSS_COMPILE = riscv64-unknown-elf-
CC = $(CROSS_COMPILE)gcc
OBJCOPY = $(CROSS_COMPILE)objcopy
CFLAGS = -march=rv32imafc -mabi=ilp32f -Os -ffunction-sections -fdata-sections
LDFLAGS = -T link.ld -Wl,--gc-sections

SRCS = main.c uart.c gpio.c
OBJS = $(SRCS:.c=.o)
TARGET = firmware.elf

all: $(TARGET)

$(TARGET): $(OBJS)
    $(CC) $(LDFLAGS) -o $@ $^

%.o: %.c
    $(CC) $(CFLAGS) -c -o $@ $<

clean:
    rm -f $(OBJS) $(TARGET)

flash: $(TARGET)
    $(OBJCOPY) -O binary $< firmware.bin
    # 这里调用你的烧录工具

这个Makefile虽然简单，但已经包含了核心逻辑：

变量定义：把工具链、编译选项、源文件都定义成变量，方便修改。
自动推导：%.o: %.c这条规则，会自动把每个.c文件编译成对应的.o文件。
依赖管理：$(TARGET): $(OBJS)，只要任何一个.o文件变了，就会重新链接。

4.3.2 进阶技巧：自动生成依赖

你想想看，如果只改了某个头文件，Makefile不知道，就不会重新编译。这会导致一些奇怪的bug。我建议加上自动依赖生成：

DEPFLAGS = -MMD -MP
CFLAGS += $(DEPFLAGS)

-include $(OBJS:.o=.d)

这样，每个.c文件编译时都会生成一个.d文件，记录了它依赖的头文件。Makefile会自动包含这些.d文件，实现头文件依赖追踪。

一个小建议： 在项目根目录建一个build/文件夹，把所有的.o和.d文件都放进去。这样源码目录保持干净，也方便.gitignore。

4.4 知识体系总览

为了让你更直观地理解这三者的关系，我画了一张图：

从这张图你可以看到，编译选项、链接脚本、Makefile这三者不是孤立的。编译选项决定了编译器怎么生成目标文件，链接脚本决定了目标文件怎么拼成最终的elf，而Makefile则把这一切自动化了。

嗯，这一章的内容就到这里。记住，工具链只是手段，理解背后的原理才是关键。下次遇到编译问题，别急着百度，先看看编译选项对不对，链接脚本有没有写错，Makefile的依赖有没有漏掉。这些基本功扎实了，什么问题都好解决。

📚 课程目录