Does linker link an object file with itself?

Question

From what I read in other SO answers, like this and this, compiler converts the source code into object file. And the object files might contain references to functions like printf that needs to be resolved by the linker.

What I don't understand is, when both declaration and definition exist in the same file, like the following case, does compiler or linker resolve the reference to return1?

Or is this just a part of the compiler optimization?

int return1();

int return2() {
  int b = return1();
  return b + 1;
}

int return1() {
  return 1;
}

int main() {
  int b = return2();
}

_{I have ensured that preprocessing has nothing to do with this by running g++ -E main.cpp.}

Update 2020-7-22

The answers are all helpful! Thanks!

From the answers below, it seems to me that the compiler may or may not resolve the reference to return1. However, I'm still unclear if there's only one translation unit, like the example I gave, and if compiler did not resolve it, does this mean that linker must resolve it then?

Since it seems to me that linker will link several (greater than one) object files together, and if there's only one translation unit (object file), linker need to link the object file with itself, am I right?

And is there anyway to know for sure which one is the case on my computer?

It depends. Both options are possible, so are options that you didn't mention, like either the compiler or the linker rearranging the code so that none of the functions exist any more. It's fine thinking about compilers emitting references to functions and linkers resolving those references as a way of understanding C++, but bear in mind is that all the compiler/linker have to do is produce a working program and there are many different ways to do that. — john, Jul 21 '20 at 11:54
@john There maybe was a misunderstanding. I only wanted it turned into an answer. No need to add something - but you can of course.... ;-) — Yunnosch, Jul 21 '20 at 12:03
Answer to the updated question. If the function return1 exists after the compiler has finished and the compiler hasn't resolved the reference to it (I think this is unlikely but it is possible) then the linker is going to have to resolve that function reference (which might also mean eliminating it). I'm not sure why you would be interested but most compilers have an option to dump out the object code they produce in human readbale form. So you could look at that. — john, Jul 22 '20 at 06:17
Thanks! As for why I'm interested, I guess it's just pure curiosity :D — Jing Zhao, Jul 22 '20 at 06:42

score 3 · Accepted Answer · answered Jul 21 '20 at 12:00

It depends. Both options are possible, so are options that you didn't mention, like either the compiler or the linker rearranging the code so that none of the functions exist any more. It's fine thinking about compilers emitting references to functions and linkers resolving those references as a way of understanding C++, but bear in mind is that all the compiler and linker have to do is produce a working program and there are many different ways to do that.

One thing the compiler and linker must do however, is make sure that any calls to standard library functions happen (like printf as you mentioned), and happen in the order that the C++ source specifies. Apart from that (and some other similar concerns) they can more or less do as they wish.

dfrib · Answer 2 · 2020-07-21T12:15:18.823

[lex.phases]/1.9, covering the final phase of translation, states [emphasis mine]:

All external entity references are resolved. Library components are linked to satisfy external references to entities not defined in the current translation. All such translator output is collected into a program image which contains information needed for execution in its execution environment.

It is, however, up to the compiler to decide whether a library component is a single translation unit or a combination of them; as governed by [lex.separate]/2 [emphasis mine]:

[ Note: Previously translated translation units and instantiation units can be preserved individually or in libraries. The separate translation units of a program communicate ([basic.link]) by (for example) calls to functions whose identifiers have external linkage, manipulation of objects whose identifiers have external linkage, or manipulation of data files. Translation units can be separately translated and then later linked to produce an executable program. — end note ]

OP: [...] does compiler or linker resolve the reference to return1?

Thus, even if return1 has external linkage, as it is defined in the translation unit where it is referred to (in return2), the linker should not need to resolve the reference to it, as its is definition exists in the current translation. The standard passage is, however, (likely intentionally) a bit vague regarding requirements for when linking to satisfy external references need to occur, and I do not see it to be a non-compliant implementation to defer resolving the reference to return1 in return2 until the linking phase.

@Yunnosch note my emphasis on _"to entitites **not defined in the current translation**"_; afaics this applies also to entities with external linkage - has the entity already been defined in the current translation (/library component) **or** does it need to be resolved by the linker? — dfrib, Jul 21 '20 at 12:07

score 1 · Answer 3 · answered Jul 21 '20 at 13:31

Practically speaking, the problem is with the following code:

static int return1();

int return2() {
  int b = return1();
  return b + 1;
}

int return1() {
  return 1;
}

The problem for the linker is that each Translation Unit can now contain its own return1, so the linker would have a problem in choosing the right return1. There are tricks around this, e.g. adding the Translation Unit name to the function name. Most ABI's do not do that, but the C++ standard would allow it. For anonymous namespaces however, i.e. namespace { int function1(); }, ABI's will use such tricks.

Does linker link an object file with itself?

3 Answers3