链接器如何跨翻译单元处理相同的模板实例化?

How does the linker handle identical template instantiations across translation units?(链接器如何跨翻译单元处理相同的模板实例化?)

问题描述

假设我有两个翻译单元:

Suppose I have two translation-units:

foo.cpp

void foo() {
  auto v = std::vector<int>();
}

void bar() {
  auto v = std::vector<int>();
}

#ifndef THING_HPP
#define THING_HPP
#ifndef ID
#error ID undefined
#endif

template<typename T>
struct thing
{
    T id() const {
        return T{ID};
    }
};

#endif

#define ID 0xf00
#include "thing.hpp"

unsigned foo()
{
    thing<unsigned> t;
    return t.id();
}

#define ID 0xb00
#include "thing.hpp"

unsigned boo()
{
    thing<unsigned> t;
    return t.id();
}

#include <iostream>

extern unsigned foo();
extern unsigned boo();

int main()
{
    std::cout << std::hex 
    << '
' << foo()
    << '
' << boo()
    << std::endl;
    return 0;
}

g++ -c -save-temps foo.cpp

    .section    .text._ZNK5thingIjE2idEv,"axG",@progbits,_ZNK5thingIjE2idEv,comdat
    .align 2
    .weak   _ZNK5thingIjE2idEv
    .type   _ZNK5thingIjE2idEv, @function
_ZNK5thingIjE2idEv:
.LFB2:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movq    %rdi, -8(%rbp)
    movl    $3840, %eax
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc

.section    .text._ZNK5thingIjE2idEv,"axG",@progbits,_ZNK5thingIjE2idEv,comdat

.weak   _ZNK5thingIjE2idEv

至关重要.它将 thing<unsigned int>::id() const 归类为 弱a> 符号.GNU 链接器识别 strong 符号和 weak 符号.对于一个强符号，链接器将只接受链接中的一个定义.如果有更多，它将给出一个倍数-定义错误.但是对于一个弱符号，它可以容忍任意数量的定义，并选择一个.如果一个弱定义的符号在链接中也有(只有一个)强定义，那么将选择强定义.如果一个符号有多个弱定义而没有强定义，然后链接器可以任意选择任何一个弱定义.

is crucial. It classifies thing<unsigned int>::id() const as a weak symbol. The GNU linker recognises strong symbols and weak symbols. For a strong symbol, the linker will accept only one definition in the linkage. If there are more, it will give a multiple -definition error. But for a weak symbol, it will tolerate any number of definitions, and pick one. If a weakly defined symbol also has (just one) strong definition in the linkage then the strong definition will be picked. If a symbol has multiple weak definitions and no strong definition, then the linker can pick any one of the weak definitions, arbitrarily.

指令:

.type   _ZNK5thingIjE2idEv, @function

将 thing::id() 归类为引用一个 函数 - 而不是数据.

classifies thing<unsigned int>::id() as referring to a function - not data.

然后在定义体中，在地址处组装代码由弱全局符号_ZNK5thingIjE2idEv标记，本地相同标记为 .LFB2.代码返回 3840 (= 0xf00).

Then in the body of the definition, the code is assembled at the address labelled by the weak global symbol _ZNK5thingIjE2idEv, the same one locally labelled .LFB2. The code returns 3840 ( = 0xf00).

接下来我们用同样的方式编译boo.cpp:

Next we'll compile boo.cpp the same way:

g++ -c -save-temps boo.cpp

再看看 thing::id() 在 boo.s

    .section    .text._ZNK5thingIjE2idEv,"axG",@progbits,_ZNK5thingIjE2idEv,comdat
    .align 2
    .weak   _ZNK5thingIjE2idEv
    .type   _ZNK5thingIjE2idEv, @function
_ZNK5thingIjE2idEv:
.LFB2:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movq    %rdi, -8(%rbp)
    movl    $2816, %eax
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc

除了我们的作弊之外，它是相同的:这个定义返回 2816 (= 0xb00).

It's identical, except for our cheat: this definition returns 2816 ( = 0xb00).

当我们在这里时，让我们注意一些可能不言而喻的事情:一旦我们进入汇编(或目标代码)，类就消失了.这里，我们的目标是:-

While we're here, let's note something that might or might not go without saying: Once we're in assembly (or object code), classes have evaporated. Here, we're down to: -

• 数据
• 代码
• 符号，可以标注数据或标注代码.

所以这里没有什么特别代表实例化 thing<T> forT = 无符号.在这种情况下，thing<unsigned> 剩下的就是_ZNK5thingIjE2idEv 的定义也就是 thing::id() const.

So nothing here specifically represents the instantiation of thing<T> for T = unsigned. All that's left of thing<unsigned> in this instance is the definition of _ZNK5thingIjE2idEv a.k.a thing<unsigned int>::id() const.

所以现在我们知道编译器在实例化thing<unsigned>方面做了什么在给定的翻译单元中.如果它必须实例化一个 thing<unsigned>成员函数，然后它组装实例化成员的定义函数在一个弱全局符号上，它标识了成员函数，并且它将此定义放入其自己的功能部分.

So now we know what the compiler does about instantiating thing<unsigned> in a given translation unit. If it is obliged to instantiate a thing<unsigned> member function, then it assembles the definition of the instantiated member function at a weakly global symbol that identifies the member function, and it puts this definition into its own function-section.

现在让我们看看链接器做了什么.

Now let's see what the linker does.

首先我们将编译主源文件.

First we'll compile the main source file.

g++ -c main.cpp

然后链接所有对象文件，请求对 _ZNK5thingIjE2idEv 的诊断跟踪，和一个链接映射文件:

Then link all the object files, requesting a diagnostic trace on _ZNK5thingIjE2idEv, and a linkage map file:

g++ -o prog main.o foo.o boo.o -Wl,--trace-symbol='_ZNK5thingIjE2idEv',-M=prog.map
foo.o: definition of _ZNK5thingIjE2idEv
boo.o: reference to _ZNK5thingIjE2idEv

所以链接器告诉我们程序从foo.o 并在 boo.o 中调用它.

So the linker tells us that the program gets the definition of _ZNK5thingIjE2idEv from foo.o and calls it in boo.o.

运行程序表明它说的是真话:

Running the program shows it's telling the truth:

./prog

f00
f00

foo() 和 boo() 都返回 thing().id() 的值在 foo.cpp 中实例化.

Both foo() and boo() are returning the value of thing<unsigned>().id() as instantiated in foo.cpp.

thing::id() const 的other 定义变成了什么在 boo.o 中?地图文件向我们展示了:

What has become of the other definition of thing<unsigned int>::id() const in boo.o? The map file shows us:

prog.map

...
Discarded input sections
 ...
 ...
 .text._ZNK5thingIjE2idEv
                0x0000000000000000        0xf boo.o
 ...
 ...

链接器丢弃了 boo.o 中的函数部分包含另一个定义.

The linker chucked away the function-section in boo.o that contained the other definition.

现在让我们再次链接 prog，但这次是在 foo.o 和 boo.o 中逆序:

Let's now link prog again, but this time with foo.o and boo.o in the reverse order:

$ g++ -o prog main.o boo.o foo.o -Wl,--trace-symbol='_ZNK5thingIjE2idEv',-M=prog.map
boo.o: definition of _ZNK5thingIjE2idEv
foo.o: reference to _ZNK5thingIjE2idEv

这一次，程序从boo.o中得到_ZNK5thingIjE2idEv的定义，并在 foo.o 中调用它.该程序确认:

This time, the program gets the definition of _ZNK5thingIjE2idEv from boo.o and calls it in foo.o. The program confirms that:

$ ./prog

b00
b00

地图文件显示:

...
Discarded input sections
 ...
 ...
 .text._ZNK5thingIjE2idEv
                0x0000000000000000        0xf foo.o
 ...
 ...

链接器丢弃了函数部分 .text._ZNK5thingIjE2idEv来自 foo.o.

that the linker chucked away the function-section .text._ZNK5thingIjE2idEv from foo.o.

这幅画就完成了.

编译器在每个翻译单元中发出一个弱定义每个实例化的模板成员都在其自己的函数部分中.链接器然后只选择它遇到的那些弱定义中的 first在链接序列中需要解析弱引用时象征.因为每个弱符号都针对一个定义，所以任何其中一个 - 特别是第一个 - 可用于解析所有引用链接中的符号，其余的弱定义是消耗品.多余的弱定义必须被忽略，因为链接器只能链接给定符号的一个定义.还有剩余链接器可以丢弃弱定义，没有抵押对程序造成损害，因为编译器将每一个都单独放在一个链接部分中.

The compiler emits, in each translation unit, a weak definition of each instantiated template member in its own function section. The linker then just picks the first of those weak definitions that it encounters in the linkage sequence when it needs to resolve a reference to the weak symbol. Because each of the weak symbols addresses a definition, any one one of them - in particular, the first one - can be used to resolve all references to the symbol in the linkage, and the rest of the weak definitions are expendable. The surplus weak definitions must be ignored, because the linker can only link one definition of a given symbol. And the surplus weak definitions can be discarded by the linker, with no collateral damage to the program, because the compiler placed each one in a linkage section all by itself.

通过选择它看到的 first 弱定义，链接器实际上是随机选择，因为目标文件的链接顺序是任意的.但这很好，只要我们遵守跨多个翻译单元的 ODR，因为我们这样做了，所以所有的弱定义确实是相同的.#include 的通常做法是从头文件的任何地方对类模板进行处理(而不是在我们这样做时宏注入任何本地编辑)是遵守规则的一种相当稳健的方式.

By picking the first weak definition it sees, the linker is effectively picking at random, because the order in which object files are linked is arbitrary. But this is fine, as long as we obey the ODR accross multiple translation units, because it we do, then all of the weak definitions are indeed identical. The usual practice of #include-ing a class template everywhere from a header file (and not macro-injecting any local edits when we do so) is a fairly robust way of obeying the rule.

这篇关于链接器如何跨翻译单元处理相同的模板实例化?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！