分析 gcc 默认链接脚本

最新推荐文章于 2024-09-18 21:50:24 发布

longyu_wlz

最新推荐文章于 2024-09-18 21:50:24 发布

阅读量3.3k

点赞数 4

分类专栏： elf 文章标签：分析 gcc 默认链接脚本 linker script linker constructor destructor

本文链接：https://blog.csdn.net/Longyu_wlz/article/details/109007373

版权

elf 专栏收录该内容

14 篇文章 3 订阅

订阅专栏

前言

在获取 gcc 默认链接脚本这篇文章中，我描述了如何传递 --verbose 给链接器以获取 gcc 使用的默认链接脚本内容的过程，执行 gcc hello.c -Wl,--verbose就能够打印出默认的链接脚本内容。

获取到默认链接脚本的内容只是第一步，有了这个输入就能够对链接脚本的内容进行分析，这就是本文的主要内容。

由于默认的链接脚本内容过长，我不贴完整的内容，只针对重要的研究对象贴上相关的代码。

使用到的一些重要的链接脚本命令基础

在阅读下面的内容前，最好先阅读 gcc x64 环境中默认链接脚本分析之链接器基础命令功能介绍这篇博客来对默认链接脚本中使用到的链接脚本基础命令的功能进行学习。

ENTRY 标号

相关内容请阅读 gcc x64 环境中默认链接脚本分析之 ENTRY 标号与 _start 函数这篇博文。

SEARCH_DIR 配置

SEARCH_DIR 命令会向 ld 查找库的路径列表中添加一个路径。使用 SEARCH_DIR(path) 与使用 ‘-L path’ 命令行参数类似。如果这两者都使用到了，链接器将会搜索这两种方式指定的所有路径。需要注意的是链接器将会优先搜索命令行中指定的路径。

默认链接脚本中的 SEARCH_DIR 的部分设置内容截取如下：

SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu"); SEARCH_DIR("=/lib/x86_64-linux-gnu");

注意这里在路径前添加了一个等号，手册中只描述了路径，并没有描述要添加一个等号。

默认链接脚本 SECTION 中的内容

默认链接脚本 SECTION 中的第一行内容如下：

  /* Read-only sections, merged into text segment: */
  PROVIDE (__executable_start = SEGMENT_START("text-segment", 0)); . = SEGMENT_START("text-segment", 0) + SIZEOF_HEADERS;

这里首先用 PROVIDE 命令设定了一个标号，并设置标号的地址为 text-segment 段的基地址，然后将文件从 text-segment 段的基地址向下扩展输出文件头部大小的空间。

这里 SEGMENT_START 的第二个参数为默认值，当链接脚本中找不到 text-segment 基地址时，SEGMENT_START 函数将会返回第二个参数指定的默认值，这里就是 0。

.interp section

init 段描述代码

.init           :
{
  KEEP (*(SORT_NONE(.init)))
}

init 段使用了 KEEP 命令来阻止链接器回收所在的 section，并且调用 SORT_NONE 对所有输入文件中的 .init 段进行排序。

在 libc 库的 crti.S、crtn.S 中有定义 init 段，用户程序中较少看到 init 段的定义内容。

text 段描述代码

  .text           :
  {
    *(.text.unlikely .text.*_unlikely .text.unlikely.*)
    *(.text.exit .text.exit.*)
    *(.text.startup .text.startup.*)
    *(.text.hot .text.hot.*)
    *(.text .stub .text.* .gnu.linkonce.t.*)
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
  }

text 段中存放了所有输入文件中的代码段，这里 .gnu.linkonce.t. section* 需要注意。这里的 .gnu.linkonce 用于在链接时遇到多个以 .gnu.linkonce 开始的相同名字的 section 时，只保留一个拷贝。

更详细的信息请访问 Linkonce vs comdat.

fini 段描述代码

  .fini           :
  {
    KEEP (*(SORT_NONE(.fini)))
  }

fini 段与 init 段功能相反，却都使用了 KEEP 命令与 SORT_NONE 命令。同样在 libc 库的 crti.S、crtn.S 中有定义 fini 段，用户程序中较少看到 fini 段的定义内容。

text 段结束的标号设定

  PROVIDE (__etext = .);
  PROVIDE (_etext = .);
  PROVIDE (etext = .);

text 段在 .fini 段之后结束，在结束位置使用 PROVIDE 命令设定了三个标号，这三个标号在上文的引用链接中已经描述了，这里就不赘述了。

rodata 段脚本

  .rodata         : { *(.rodata .rodata.* .gnu.linkonce.r.*) }

rodata 段放一些只读数据的内容，如字符串常量等等，代码非常简单直接跳过。

preinit_array、init_array、fini_array 段脚本

相关内容描述请阅读 gcc x64 环境中默认链接脚本分析之 preinit_array、constructor、destructor 相关分析这篇博文。

ctors 与 dtors 段脚本

 .ctors          :
  {
	..............
    KEEP (*crtbegin.o(.ctors))
    KEEP (*crtbegin?.o(.ctors))
	..............
    KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
  }

  .dtors          :
  {
    KEEP (*crtbegin.o(.dtors))
    KEEP (*crtbegin?.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
  }

ctors 与 dtors 段描述代码设定了构造函数与析构函数的布局，链接脚本中要对其进行排序以保证按照正确的顺序执行。

由于 gcc 使用 crtbegin.o 来查找第一个构造函数的位置，因此 ctors 段描述代码中将 crtbegin.o 中的 ctors 段放在输出文件的 ctors段的起始位置。

同时 crtend.o 中的 ctor 函数需要最后执行，因此先使用 EXCLUDE_FILE 来输出其它文件中的 ctors 段内容，dtors 段描述代码中也有类似的执行逻辑。

这里涉及的 crtbegin.o 和 crtend.o 两个文件在 libc 库中没有找到相关的代码，网上搜索发现这两个文件是 libc++ 库中的，用于配合 glibc 实现 C++ 的全局构造和析构功能。

data 段脚本

  .data           :
  {
    *(.data .data.* .gnu.linkonce.d.*)
    SORT(CONSTRUCTORS)
  }

data 段也相当简单，CONSTRUCTORS 命令却比表面上看上去更复杂。它用于 a.out 格式文件链接时，链接器使用的特殊构造集合以支持 C++ 全局构造函数与析构函数，更详细的信息可以阅读 gnu Linker 手册中 3.6.6 小节的内容。

bss 段脚本

  .bss            :
  {
   *(.dynbss)
   *(.bss .bss.* .gnu.linkonce.b.*)
   *(COMMON)
   /* Align here to ensure that the .bss section occupies space up to
      _end.  Align after .bss to ensure correct alignment even if the
      .bss section disappears because there are no input sections.
      FIXME: Why do we need it? When there is no .bss section, we don't
      pad the .data section.  */
   . = ALIGN(. != 0 ? 64 / 8 : 1);
  }

这里 COMMON section 值得研究，它是一个特殊的普通符号的概念，因为在许多对象文件格式中普通符号没有一个特定的输入 section。它一般被放在 bss 段中（摘自 gnu linker 手册）。

debug 信息相关 section 段脚本

  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line .debug_line.* .debug_line_end ) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
	.............

debug 信息在 gcc 指定了 -g 参数后会生成，gdb 调试程序时就会尝试获取程序中的 debug 信息。

我指定 -g 参数编译一个简单的程序，查看 map 文件得到了如下信息：

407 
408 .debug_aranges  0x0000000000000000       0x30
409  *(.debug_aranges)
410  .debug_aranges
411                 0x0000000000000000       0x30 /tmp/cc9Ez1ky.o
412 
413 .debug_pubnames
414  *(.debug_pubnames)
415 
416 .debug_info     0x0000000000000000      0x31b
417  *(.debug_info .gnu.linkonce.wi.*)
418  .debug_info    0x0000000000000000      0x31b /tmp/cc9Ez1ky.o
419 
420 .debug_abbrev   0x0000000000000000       0xe8
421  *(.debug_abbrev)
422  .debug_abbrev  0x0000000000000000       0xe8 /tmp/cc9Ez1ky.o
423 
424 .debug_line     0x0000000000000000      0x11c
425  *(.debug_line .debug_line.* .debug_line_end)
426  .debug_line    0x0000000000000000      0x11c /tmp/cc9Ez1ky.o
427 
428 .debug_frame
429  *(.debug_frame)
430 
431 .debug_str      0x0000000000000000      0x269
432  *(.debug_str)
433  .debug_str     0x0000000000000000      0x269 /tmp/cc9Ez1ky.o

查看 debug_str section 的内容，获取到的信息部分内容截取如下：

[longyu@debian-10:22:43:16] program-problem $ readelf -p .debug_str ./a.out

String dump of section '.debug_str':
  [     0]  _IO_buf_end
  [     c]  _old_offset
  [    18]  sys_nerr
  [    21]  _IO_save_end
  [    2e]  short int
  [    38]  size_t
  [    3f]  _IO_write_ptr
  [    4d]  _flags
  [    54]  _IO_buf_base
  [    61]  _markers
  [    6a]  _IO_read_end
  [    77]  /home/longyu/problem_and_solution/program-problem```

这里能够看到源代码的路径与一些地址及数据大小的字符串信息。

查看 debug_line section 内容获取到的信息部分截取如下：

[longyu@debian-10:22:43:36] program-problem $ readelf -p .debug_line ./a.out

String dump of section '.debug_line':
  [    1b]  .
  [    1d]  /usr/lib/gcc/x86_64-linux-gnu/8/include
  [    45]  /usr/include/x86_64-linux-gnu/bits
  [    68]  /usr/include/x86_64-linux-gnu/bits/types
  [    91]  /usr/include
  [    9f]  hello.c