对于RISV -V处理器，详解 gcc 编译器，Makefile中gcc编译器参数的含义

ESWIN5199

已于 2024-07-24 15:08:50 修改

阅读量3.8k

点赞数 4

文章标签： java servlet 前端

于 2022-09-05 20:25:52 首次发布

本文链接：https://blog.csdn.net/qq_45519101/article/details/126711958

版权

GCC编译器的版本：

1：以“riscv64/32-unknown-linux-gnu-”为前缀的版本

riscv64-unknown-linux-gnu-gcc（编译器）

riscv64-unknown-linux-gnu-gdb （调试器）

riscv64-unknown-linux-gnu-ar （文件归档，制作库文件，用于静态链接库或者动态链接库）

riscv64-unknown-elf-objdump （反汇编器）

riscv64-unknown-elf-objcopy （将elf文件转化位hex或者ihex文件）

................................................

riscv64-unknown-linux-gnu-”前缀表示该版本的工具链是64位架构的Linux版本工具链。注意：此Linux不是指当前版本工具链一定要运行在Linux操作系统的电脑上，此Linux是指该GCC工具链会使用Linux的Glibc作为C运行库。此处的前缀riscv64（还有riscv32的版本）与运行在64位或者32位电脑上毫无关系，此处的64和32是指如果没有通过-march和-mabi选项指定RISC-V架构的位宽，默认将会按照64位还是32位的RISC-V架构来编译程序。有关-march和-mabi选项的含义。

2: 以“riscv64-unknown-elf-”为前缀的版本

同上

以“riscv64-unknown-elf-”为前缀的版本表示该版本为非Linux（Non-linux）版本的工具链，此Non-Linux不是指当前版本工具链一定不能运行在Linux操作系统的电脑上，此Non-Linux是指该GCC工具链会使用newlib作为C运行库。同上理，此处的前缀riscv64（还有riscv32的版本）与运行在64位或者32位电脑上毫无关系，此处的64和32是指如果没有通过-march和-mabi选项指定RISC-V架构的位宽，默认将会按照64位还是32位的RISC-V架构来编译程序。有关-march和-mabi选项的含义。

3：以“riscv-none-embed-”为前缀的版本

同上

以“riscv-none-embed-”为前缀的版本表示是最新为裸机（bare-metal）嵌入式系统而生成的交叉编译工具链，所谓裸机（bare-metal）是嵌入式领域的一个常见形态，表示不运行操作系统的系统。该版本使用新版本的newlib作为C运行库，并且支持newlib-nano，能够为嵌入式系统生成更加优化的代码体积（Code Size）。

RISV-V处理器中gcc编译器参数的含义：

-march:

由于RISC-V的指令集是模块化的指令集，因此在为目标RISC-V平台进行交叉编译之时，需要通过选项指定目标RISC-V平台所支持的模块化指令集组合，该选项为（-march=），有效的选项值如下：

        rv32i[m][a][f[d]][c]
        rv32g[c]
        rv64i[m][a][f[d]][c]
        rv64g[c]

在上述选项中rv32表示目标平台是32位架构，rv64表示目标平台是64位架构，其他i/m/a/f/d/c/g分别代表了RISC-V模块化指令子集的字母简称。

-mabi

由于RISC-V的指令集是模块化的指令集，因此在为目标RISC-V平台进行交叉编译之时，需要通过选项指定嵌入式RISC-V目标平台所支持的ABI函数调用规则（有关ABI函数调用规则的相关信息请参见RISC-V中文书籍《手把手教你设计CPU——RISC-V处理器篇》中附录A的图A-1）。RISC-V定义了两种整数的ABI调用规则和三种浮点ABI调用规则，通过选项（-abi=）指明，有效的选项值如下：

        ilp32
        ilp32f
        ilp32d
        lp64
        lp64f
        lp64d

细节解析参考：https://blog.csdn.net/qq_39507748/article/details/115347636?spm=1001.2101.3001.6650.13&utm_medium=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~Rate-13-115347636-blog-126669424.topnsimilarv1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~Rate-13-115347636-blog-126669424.topnsimilarv1&utm_relevant_index=14

-mcmodel

目前RISC-V GCC工具链认为，在实际的情形中，一个程序的大小一般不会超过4GB的大小，因此在程序内部的寻址空间不能超过4GB的空间。而在64位的架构中，地址空间的大小远远的大于4GB的空间，因此针对RV64架构而言，RISC-V GCC工具链定义了（–mcmodel=）选项用于指定寻址范围的模式，使得编译器在编译阶段能够按照相应的策略编译生成代码。其有效的选项值如下

-mcmodel=medlow

-mcmodel==medlow 选项用于指示该程序的寻址范围固定只能在-2GB至+2GB的空间内。注意：地址区间没有负数可言，-2GB是指整个64位地址空间最高2GB地址区间。
由于此模式的寻址空间是固定的-2GB至+2GB的空间内，因此编译器能够相对生成比较高效的代码，但是由于寻址空间固定，对于整个64位的大多数地址空间都无法访问到。

-mcmodel=medany

-mcmodel==medlow 选项用于指示该程序的寻址范围可以在任意的一个4G空间内。由于此模式的寻址空间不是固定的，所以相对比较灵活。

细节解析参考：

https://blog.csdn.net/qq_39507748/article/details/115347636?spm=1001.2101.3001.6650.13&utm_medium=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~Rate-13-115347636-blog-126669424.topnsimilarv1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~Rate-13-115347636-blog-126669424.topnsimilarv1&utm_relevant_index=14

-ffunction-section -fdata-section

有时我们的程序会定义一些暂时使用不上的功能和函数，虽然我们不使用这些功能和函数，但它们往往会浪费我们的 ROM 和 RAM 的空间。这在使用静态库时，体现的更为严重。有时，我们只使用了静态库仅有的几个功能，但是系统默认会自动把整个静态库全部链接到可执行程序中，造成可执行程序的大小大大增加。

为了解决前面分析的问题，我们引入了标题中的几个参数。GCC 链接操作是以 section 作为最小的处理单元，只要一个 section 中的某个符号被引用，该 section 就会被加入到可执行程序中去。

因此，GCC 在编译时可以使用 -ffunction-sections 和 -fdata-sections 将每个函数或符号创建为一个 sections，其中每个 sections 名与 function 或 data 名保持一致。而在链接阶段， -Wl,–gc-sections 指示链接器去掉不用的section（其中-wl, 表示后面的参数 -gc-sections 传递给链接器），这样就能减少最终的可执行程序的大小了。

细节解析参考：https://blog.csdn.net/itworld123/article/details/124465741

--specs=nano.specs

-specs 的作用

原来咱们执行的 gcc 并不是真正的编译器，而是 driver ，即驱动器，gcc 驱动器根据命令行的参数再调用真正的编译器（cc1,cc1plus）、汇编器（as）、链接器（ld）。gcc 驱动器调用 cc1、as、ld 时遵循一定的规则，这个规则就叫做 specs，gcc 有一套自带的 specs

如果命令行中没有指定 -specs=file 参数，那么 gcc 就使用自带的 specs，如果指定了 -specs=file 参数，那么在处理完自带的 specs 后，继续处理参数给出的 specs 文件，而且可以通过多个 -specs=file 参数指定多个 specs 文件，gcc 会按出现的次序依次处理。后面的 specs 文件可以覆盖、修改、删除前面的 specs 中的规则。

nona.specs 将 -lc 替换成 -lc_nano，即：使有精简版的C库替代标准C库。精简的C库有些特性是被排除掉的，比如 printf* 系列函数不支持浮点数的格式化，因为做了精简，因此最终生成的程序映像要比使用标准C库要小一些。如果没有用到这部分特性，就可以通过 -specs=nano.specs 节约有限的代码空间，如果使用了该参数后发现有些C库函数行为不符合预期，比如 sprintf 没有格式化浮点数，那么将这个参数去掉。

细节解析参考：https://blog.csdn.net/zoomdy/article/details/100727279

-D

请参考我的另一篇文章：在Makefile文件中，gcc -D的作用_ESWIN5204的博客-CSDN博客