GCC：避免在使用静态数组时长时间链接

Question

我的问题实际上是重复this one，它会问为什么会出现此问题。我想知道是否可以避免它。

问题是：如果我静态分配大量内存：

unsigned char static_data[ 8 * BYTES_IN_GYGABYTE ];

然后链接器（ld）需要很长时间才能生成可执行文件。 @davidg对我上面提到的这个问题有一个很好的解释：

  

这给我们留下了以下一系列步骤：

     

  

1. 汇编程序告诉链接器它需要创建一个1GB长的内存段。

  

2. 链接器继续并分配此内存，准备将其放入最终的可执行文件中。

  

3. 链接器意识到此内存位于.bss部分并标记为NOBITS，这意味着数据只是0，并且不需要物理放入最终的可执行文件中。它避免写出1GB的数据，而只是抛弃分配的内存。

  

4. 链接器只向编译的代码写入最终的ELF文件，生成一个小的可执行文件。

        

更智能的链接器可能能够避免上面的步骤2和3，使编译时间更快

确定。 @davidg解释了为什么链接器需要花费大量时间，但我想知道如何避免它。也许GCC有一些选择，会对链接器说be a little smarter和avoid steps 2 and 3 above？

谢谢。

P.S。我在Ubuntu上使用GCC 4.5.2

Answer 1

您只能在发布版本中分配静态内存：

#ifndef _DEBUG
    unsigned char static_data[ 8 * BYTES_IN_GYGABYTE ];
#else
    unsigned char *static_data;
#endif

Answer 2

我会想到两个有用的想法：

1. 正如在一些评论中已经提到的：将它放在一个单独的编译单元中。这本身不会减少链接时间。但也许与增量链接一起帮助（ld选项-r）。
2. 其他类似。将其放在单独的编译单元中，并从中生成共享库。稍后再与共享库链接。

可悲的是我不能保证其中一个有用，因为我无法测试：我的gcc（4.7.2）和bin工具不显示这个耗时的行为，8,16或32千兆字节的测试程序编译和链接一秒钟之内。