crtbegin.o，crtbeginT.o和crtbeginS.o有什么区别？

问题描述

我试图使用 ld 直接链接以隔离构建问题。

code> /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc ++。所以，我遇到了一些问题：

  ac-aaa.o：在函数`__static_initialization_and_destruction_0'中：
 /usr/include/c++/4.7/iostream:75：undefined对`__dso_handle'的引用
 ac-callback.o：在函数`__static_initialization_and_destruction_0'中：
 /usr/include/c++/4.7/iostream:75：未定义引用`__dso_handle'
 ... 
  

搜索 __ dso_handle ：

  $ grep __dso_handle /usr/lib/gcc/x86_64-linux-gnu/4.7/* 
二进制文件/ usr / lib / gcc / x86_64-linux-gnu / 4.7 / cc1plus匹配
二进制文件/usr/lib/gcc/x86_64-linux-gnu/4.7/crtbegin.o匹配
二进制文件/usr/lib/gcc/x86_64-linux-gnu/4.7/ crtbeginS.o matches 
二进制文件/usr/lib/gcc/x86_64-linux-gnu/4.7/crtbeginT.o matches 
  

crtbegin.o ， crtbeginT.o 和<$ c之间有什么区别$ c> crtbeginS.o ？

解决方案

http://dev.gentoo.org/~vapier/crt.txt =nofollow> http://dev.gentoo.org/~vapier/crt.txt

$ b

$ b b

 一些定义：
 PIC  - 位置无关代码（-fPIC）
 PIE  - 与位置无关的可执行文件（-fPIE -pie）
 crt  -  C运行时
 
 
 
 crt0.o crt1.o等... 
有些系统使用crt0.o，有些使用crt1.o（有些系统甚至使用crt2.o 
或更高版本）。最有可能是由于某些目标
的过渡阶段。具体的数字否则是完全任意的 - 看内部gcc端口代码
，以确定你的目标期望什么。所有
重要的是，无论gcc编码，你的C库更好地使用
同名。 
 
此对象应包含_start符号，该符号负责
引导程序的初始执行。 
是什么意思是高度libc依赖，因此，该对象由
 C库提供，不能与其他混合。 
 
在uClibc / glibc系统上，此对象初始化非常早的ABI需求
（类似于堆栈或帧指针），设置argc / argv / env值，然后
将指针传递到init / fini / main函数到内部libc main 
，然后在最终调用真正的
 main函数之前进行更一般的引导。 
 
 glibc ports调用此文件'start.S'，而uClibc端口调用此crt0.S或
 crt1.S（取决于它们的gcc期望）。 
 
 crti.o 
定义.init和.fini段的函数前言（分别使用_init 
和_fini符号）。这样他们可以直接调用。这些
符号也触发链接器生成DT_INIT / DT_FINI动态ELF标签。 
 
这些是支持旧式构造函数/析构函数系统，其中所有的
 .init / .fini节在链接时被连接。不要与
更新的优先级构造函数/析构函数.init_array / .fini_array节和
 DT_INIT_ARRAY / DT_FINI_ARRAY ELF标记混淆。 
 
 glibc端口用于调用这个'initfini.c'，但现在使用'crti.S'。 uClibc 
也使用'crti.S'。 
 
 crtn.o 
定义.init / .fini段的函数epilogs。参见crti.o. 
 
 glibc端口用于调用此'initfini.c'，但现在使用'crtn.S'。 uClibc 
也使用'crtn.S'。 
 
 Scrt1.o 
在生成PIE时用于代替crt1.o。 
 gcrt1.o 
在使用概要分析信息生成代码时用于代替crt1.o。 
使用-pg编译。生成适合gprof util的输出。 
 Mcrt1.o 
像gcrt1.o，但是与prof实用程序一起使用。 glibc将此安装为
一个虚拟文件，因为它在Linux系统上无用。 
 
 crtbegin.o 
 GCC使用它来查找构造函数的开始。 
 crtbeginS.o 
生成共享对象/ PIE时用于代替crtbegin.o。 
 crtbeginT.o 
生成静态可执行文件时用于代替crtbegin.o。 
 crtend.o 
 GCC使用它来查找析构函数的开始。 
 crtendS.o 
生成共享对象/ PIE时用于代替crtend.o。 
 
 
 
一般链接顺序：
 crt1.o crti.o crtbegin.o [-L paths] [user objects] [gcc libs] [C libs] [gcc libs] crtend.o crtn.o 
 
 
 
更多参考文献：
 http://gcc.gnu.org/onlinedocs/gccint/Initialization.html 
  

I'm trying to link directly using ld to isolate a build problem.

When I include /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so, I get a few issues:

ac-aaa.o: In function `__static_initialization_and_destruction_0':
/usr/include/c++/4.7/iostream:75: undefined reference to `__dso_handle'
ac-callback.o: In function `__static_initialization_and_destruction_0':
/usr/include/c++/4.7/iostream:75: undefined reference to `__dso_handle'
...

Searching for __dso_handle:

$ grep __dso_handle  /usr/lib/gcc/x86_64-linux-gnu/4.7/*
Binary file /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus matches
Binary file /usr/lib/gcc/x86_64-linux-gnu/4.7/crtbegin.o matches
Binary file /usr/lib/gcc/x86_64-linux-gnu/4.7/crtbeginS.o matches
Binary file /usr/lib/gcc/x86_64-linux-gnu/4.7/crtbeginT.o matches

What is the difference between crtbegin.o, crtbeginT.o and crtbeginS.o?

解决方案

You will find nice explanation here: http://dev.gentoo.org/~vapier/crt.txt

I will quote it following, in case that URL disappears.

---

Mini FAQ about the misc libc/gcc crt files.

Some definitions:
PIC - position independent code (-fPIC)
PIE - position independent executable (-fPIE -pie)
crt - C runtime



crt0.o crt1.o etc...
  Some systems use crt0.o, while some use crt1.o (and a few even use crt2.o
  or higher).  Most likely due to a transitionary phase that some targets
  went through.  The specific number is otherwise entirely arbitrary -- look
  at the internal gcc port code to figure out what your target expects.  All
  that matters is that whatever gcc has encoded, your C library better use
  the same name.

  This object is expected to contain the _start symbol which takes care of
  bootstrapping the initial execution of the program.  What exactly that
  entails is highly libc dependent and as such, the object is provided by
  the C library and cannot be mixed with other ones.

  On uClibc/glibc systems, this object initializes very early ABI requirements
  (like the stack or frame pointer), setting up the argc/argv/env values, and
  then passing pointers to the init/fini/main funcs to the internal libc main
  which in turn does more general bootstrapping before finally calling the real
  main function.

  glibc ports call this file 'start.S' while uClibc ports call this crt0.S or
  crt1.S (depending on what their gcc expects).

crti.o
  Defines the function prologs for the .init and .fini sections (with the _init
  and _fini symbols respectively).  This way they can be called directly.  These
  symbols also trigger the linker to generate DT_INIT/DT_FINI dynamic ELF tags.

  These are to support the old style constructor/destructor system where all
  .init/.fini sections get concatenated at link time.  Not to be confused with
  newer prioritized constructor/destructor .init_array/.fini_array sections and
  DT_INIT_ARRAY/DT_FINI_ARRAY ELF tags.

  glibc ports used to call this 'initfini.c', but now use 'crti.S'.  uClibc
  also uses 'crti.S'.

crtn.o
  Defines the function epilogs for the .init/.fini sections.  See crti.o.

  glibc ports used to call this 'initfini.c', but now use 'crtn.S'.  uClibc
  also uses 'crtn.S'.

Scrt1.o
  Used in place of crt1.o when generating PIEs.
gcrt1.o
  Used in place of crt1.o when generating code with profiling information.
  Compile with -pg.  Produces output suitable for the gprof util.
Mcrt1.o
  Like gcrt1.o, but is used with the prof utility.  glibc installs this as
  a dummy file as it's useless on linux systems.

crtbegin.o
  GCC uses this to find the start of the constructors.
crtbeginS.o
  Used in place of crtbegin.o when generating shared objects/PIEs.
crtbeginT.o
  Used in place of crtbegin.o when generating static executables.
crtend.o
  GCC uses this to find the start of the destructors.
crtendS.o
  Used in place of crtend.o when generating shared objects/PIEs.



General linking order:
crt1.o crti.o crtbegin.o [-L paths] [user objects] [gcc libs] [C libs] [gcc libs] crtend.o crtn.o



More references:
    http://gcc.gnu.org/onlinedocs/gccint/Initialization.html

这篇关于crtbegin.o，crtbeginT.o和crtbeginS.o有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！