gfortran 傻瓜版： mcmodel=medium 到底是做什么的？

我有一些代码在编译时出现重定位错误，下面是说明该问题的示例：

  program main
  common/baz/a,b,c
  real a,b,c
  b = 0.0
  call foo()
  print*, b
  end

  subroutine foo()
  common/baz/a,b,c
  real a,b,c

  integer, parameter :: nx = 450
  integer, parameter :: ny = 144
  integer, parameter :: nz = 144
  integer, parameter :: nf = 23*3
  real :: bar(nf,nx*ny*nz)

  !real, allocatable,dimension(:,:) :: bar
  !allocate(bar(nf,nx*ny*nz))

  bar = 1.0
  b = bar(12,32*138*42)

  return
  end

编译这个gfortran -O3 -g -o test test.f，我收到以下错误：

relocation truncated to fit: R_X86_64_PC32 against symbol `baz_' defined in COMMON section in /tmp/ccIkj6tt.o

但如果我使用的话它会起作用gfortran -O3 -mcmodel=medium -g -o test test.f。另请注意，如果我使数组可分配并在子例程中分配它，它就会起作用。

我的问题是到底是什么-mcmodel=medium做？我的印象是代码的两个版本（带有allocatable数组和没有数组的数组）或多或少是等效的......

Since bar相当大，编译器会生成静态分配而不是在堆栈上自动分配。静态数组是用以下命令创建的.comm汇编指令，在所谓的 COMMON 部分中创建分配。来自该部分的符号被收集，同名符号被合并（减少到一个符号请求，其大小等于所请求的最大大小），然后其余部分被映射到大多数可执行格式的 BSS（未初始化数据）部分。使用 ELF 可执行文件.bss部分位于数据段中，就在堆的数据段部分之前（还有另一个由匿名内存映射管理的堆部分，它不驻留在数据段中）。

随着small内存模型 32 位寻址指令用于对 x86_64 上的符号进行寻址。这使得代码更小并且速度更快。使用时的一些汇编输出small内存模型：

movl    $bar.1535, %ebx    <---- Instruction length saving
...
movl    %eax, baz_+4(%rip) <---- Problem!!
...
.local  bar.1535
.comm   bar.1535,2575411200,32
...
.comm   baz_,12,16

这使用 32 位移动指令（5 个字节长）来放置bar.1535符号（该值等于符号位置的地址）到低32位RBX寄存器（高 32 位清零）。这bar.1535符号本身是使用分配的.comm指示。内存为baz随后分配 COMMON 块。因为bar.1535非常大，baz_从开始到结束超过 2 GiB.bss部分。这在第二个中提出了问题movl指令，因为非 32 位（有符号）偏移量来自RIP应该用来解决b变量，其中的值EAX必须搬进去。这仅在链接期间检测到。汇编器本身不知道适当的偏移量，因为它不知道指令指针的值是多少（RIP）将是（它取决于加载代码的绝对虚拟地址，这是由链接器确定的），所以它只是放置一个偏移量0然后创建一个类型的重定位请求R_X86_64_PC32。它指示链接器修补以下值0与实际的偏移值。但它不能这样做，因为偏移值不适合有符号的 32 位整数，因此会退出。

随着medium内存模型看起来像这样：

movabsq $bar.1535, %r10
...
movl    %eax, baz_+4(%rip)
...
.local  bar.1535
.largecomm      bar.1535,2575411200,32
...
.comm   baz_,12,16

首先，使用 64 位立即数移动指令（10 字节长）来放置表示地址的 64 位值bar.1535进入寄存器R10。内存为bar.1535符号是使用分配.largecomm指令，因此它结束于.lbssELF 可执行文件的部分。.lbss用于存储可能不适合前 2 GiB 的符号（因此不应使用 32 位指令或 RIP 相对寻址来寻址），而较小的东西则用于存储.bss (baz_仍然使用分配.comm并不是.largecomm）。自从.lbss部分放置在.bssELF 链接器脚本中的部分，baz_使用 32 位 RIP 相关寻址不会最终导致无法访问。

所有寻址模式均在System V ABI：AMD64 架构处理器补充。这是一本厚重的技术读物，但对于真正想了解 64 位代码如何在大多数 x86_64 Unix 上工作的人来说，这是必读的。

When an ALLOCATABLE而是使用数组，gfortran分配堆内存（考虑到分配的大小，最有可能实现为匿名内存映射）：

movl    $2575411200, %edi
...
call    malloc
movq    %rax, %rdi

这基本上是RDI = malloc(2575411200)。从此以后的元素bar通过使用存储在中的值的正偏移量来访问RDI:

movl    51190040(%rdi), %eax
movl    %eax, baz_+4(%rip)

对于从开始时起超过 2 GiB 的位置bar，使用更复杂的方法。例如。实施b = bar(12,144*144*450) gfortran emits:

; Some computations that leave the offset in RAX
movl    (%rdi,%rax), %eax
movl    %eax, baz_+4(%rip)

此代码不受内存模型的影响，因为没有对进行动态分配的地址进行任何假设。此外，由于数组没有被传递，因此没有构建描述符。如果添加另一个采用假定形状数组的函数并传递bar对它来说，一个描述符bar被创建为自动变量（即在堆栈上foo）。如果数组是静态的SAVE属性，描述符被放置在.bss部分：

movl    $bar.1580, %edi
...
; RAX still holds the address of the allocated memory as returned by malloc
; Computations, computations
movl    -232(%rax,%rdx,4), %eax
movl    %eax, baz_+4(%rip)

第一步准备函数调用的参数（在我的示例案例中call boo(bar) where boo有一个接口将其声明为采用假定形状数组）。它移动数组描述符的地址bar into EDI。这是一个 32 位立即移动，因此描述符预计位于前 2 GiB 中。事实上，它被分配在.bss同时small and medium内存模型如下：

.local  bar.1580
.comm   bar.1580,72,32