默认情况下面，GCC risc-v 使用的 code model 是 medlow，在这种情况下，编译器生成的代码使用 lui 来构造全局变量的地址。
比如下面这段代码：
char x[2u * 1024 * 1024 * 1024];
int main() {
x[0] = 42;
return 0;
}
riscv64-unknown-elf-gcc main.c --save-temps -O2以后，生成的汇编代码如下：
main:
lui a5,%hi(x)
li a4,42
sb a4,%lo(x)(a5)
li a0,0
ret
单就这里而言，既然使用 lui 来生成地址，那么所能够访问的地址范围应该是 4G 才对（为了让讨论简单一些，我们先假设目标系统是 32 位的）。
但是，事实上，如果你真的尝试编译，就会遇到下面这个链接错误：
riscv64-unknown-elf/lib/crt0.o: in function `.L0 ':
(.text+0xc): relocation truncated to fit: R_RISCV_PCREL_HI20 against symbol `_end' defined in .bss section in a.out
简单说就是我们这个程序的代码+全局变量超过了 2G，所以出错了。这显然跟我们前面说的 4G 的地址范围相冲突。
由于网上也没有搜索到相关的信息，这里我们只能够从错误日志入手，尝试看看这个 _end 是从哪里冒出来的。
这里有个小陷阱：链接出错是在 crt0.o 这个目标文件里面的，而它并不是我们自己的代码，所以如果你是在前面编译的中间产物里寻找 _end，将一无所获（我就因为这个很简单的问题折腾了很久）。
事实上，我们自己 main.c 生成的代码是完全没有问题的，问题出在 crt0.o：
# riscv64-unknown-elf-objdump -dtr path/to/crt0.o
Disassembly of section .text:
0000000000000000 <_start>:
0: 00000197 auipc gp,0x0
0: R_RISCV_PCREL_HI20 __global_pointer$
4: 00018193 mv gp,gp
4: R_RISCV_PCREL_LO12_I .L1^B1
8: 00000517 auipc a0,0x0
8: R_RISCV_PCREL_HI20 _edata
8: R_RISCV_RELAX *ABS*
c: 00050513 mv a0,a0
c: R_RISCV_PCREL_LO12_I .L0
c: R_RISCV_RELAX *ABS*
10: 00000617 **auipc a2,0x0**
10: R_RISCV_PCREL_HI20 _end
10: R_RISCV_RELAX *ABS*
根据错误日志，他在重写 .text+0xc 处代码的时候出了问题。.text+0xc 的后一个指令使用了 auipc 来生成 _end 的地址，而使用 auipc 时，寻址范围是 PC ± 2G，所以就有了最开始我们看到的那条出错信息。
另一种寻找
_end的方式是编译一个不超过 2G 的程序，然后查看最后的可执行文件。
总结一下。medlow 生成的代码其实是确确实实能给访问 4G 地址空间的，但由于链接器不知道这个信息，在链接的时候使用的其他目标文件是 medany，才使得 medlow 模式下，代码+全局变量不能超过 2G。
当然，如果要支持 4G，只需要让链接器也支持两种模式就可以了（必要性不大就是，一般一个程序不会大得这么离谱）。
最后再说说 64 位的情况。我们有没有办法在 64 位机器上，支持超过 4G 的大程序？——答案是可以，但成本太过于高昂。
假设我们要支持 2^64 的代码+全局变量。在这种情况下，为了生成一个地址，编译器需要：
- 使用
lui加载最高的 20 位 -
addi加上 32~43 这 12 位，从而得到地址的高 32 位（但此时这个值在寄存器的低 32 位） -
slli将前述 32 位地址左移 32 位，把它放到寄存器的高 32 位 - 继续
lui、addi，构造地址的低 32 位，然后加上高 32 位，就得到了完整的 64 位地址。
可以看到，为了支持这种大程序，每个针对全局变量（可以把函数地址也当作“全局变量”）的读写，构造地址的成本都会变得非常大。
也因为这样大的程序在现实中几乎不太可能存在，GCC 也就没有必要费力去支持它了。
