在g ++中使用符号'_end'会导致分段错误

Max*_*dov 8 linker gcc clang

考虑以下c ++源代码:

int _end[1050];

int main() {
    for (int i = 0; i < 1050; i++)
        _end[i] = 0;
    return 0;
}
Run Code Online (Sandbox Code Playgroud)

编译线: g++ main.cpp -o main -O0

在Ubuntu 14.04下使用gcc-4.8.4和clang-3.6.0时,运行此代码会导致分段错误.奇怪的行为是符号_end指向静态分配的数组的末尾_end,而不是它的开头.如果我们替换_endend_,一切工作正常.

此外,如果我们要求gcc通过提供-S命令行参数输出汇编代码,则带有"_end"的版本与具有任何其他数组名称的版本之间没有显着差异:

$ g++ main.cpp -o main.s -O0 -S
$ g++ main2.cpp -o main2.s -O0 -S
$ diff main.s main2.s
1,2c1,2
<   .file   "main.cpp"
<   .globl  _end
---
>   .file   "main2.cpp"
>   .globl  end_
5,7c5,7
<   .type   _end, @object
<   .size   _end, 4200
< _end:
---
>   .type   end_, @object
>   .size   end_, 4200
> end_:
25c25
<   movl    $0, _end(,%rax,4)
---
>   movl    $0, end_(,%rax,4)
Run Code Online (Sandbox Code Playgroud)

但是如果我们使用objdump来转储可执行文件并对它们运行diff,我们将会看到在_end版本中使用的地址比所需的更多4200 = 4*1050字节:

$ g++ main.cpp -o main -O0
$ g++ main2.cpp -o main2 -O0
$ objdump -d main >main.dump
$ objdump -d main2 > main2.dump
$ diff main.dump main2.dump
2c2
< main:     ?????? ????? elf64-x86-64    // "File format" in Russian
---
> main2:     ?????? ????? elf64-x86-64
123c123
<   4004ff: c7 04 85 c8 20 60 00    movl   $0x0,0x6020c8(,%rax,4)
---
>   4004ff: c7 04 85 60 10 60 00    movl   $0x0,0x601060(,%rax,4)
Run Code Online (Sandbox Code Playgroud)

据我所知,gcc编译器可能会根据需要处理以下划线开头的变量,即在代码中使用这些符号是一种不好的做法.但我的问题是:这里到底发生了什么?为什么_end替换为已分配数组末尾的地址?如果我们使用"-S"命令行参数,为什么没有区别,但创建的二进制文件实际上有区别?在这种情况下,gcc和clang的表现并不一样,这对我来说也很奇怪.

vso*_*tco 3

以 开头的令牌_是保留的,您不应该使用它们。似乎_end是为在 Linux 上编译的程序定义的外部符号,表示未初始化数据段(也称为 BSS 段)末尾之后的第一个地址。

注意:在某些系统上,这些符号的名称前面带有下划线,例如:_etext、_edata 和 _end。

资料来源: http: //man7.org/linux/man-pages/man3/end.3.html