How does linker resolve references to data object in shared libraries at link time?

Question

I am learning about linking and found a small question that I could not understand.

Consider the following files:

main.c

#include "other.h"
extern int i;
int main() {
  ++i;
  inci();
  return 0;
}

other.c

int i = 0;
void inci() {
  ++i;
}

Then I compile these two files:

gcc -c main.c
gcc -shared -fpic other.c -o libother.so
gcc -o main main.o ./libother.so

Here is part of the dissasemble of main.o:

   f:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # 15 <main+0x15>
  15:   83 c0 01                add    $0x1,%eax
  18:   89 05 00 00 00 00       mov    %eax,0x0(%rip)        # 1e <main+0x1e>
  1e:   b8 00 00 00 00          mov    $0x0,%eax
  23:   e8 00 00 00 00          call   28 <main+0x28>

Here is part of the disassemble of main:

    1148:   8b 05 ca 2e 00 00       mov    0x2eca(%rip),%eax        # 4018 <i@@Base>
    114e:   83 c0 01                add    $0x1,%eax
    1151:   89 05 c1 2e 00 00       mov    %eax,0x2ec1(%rip)        # 4018 <i@@Base>
    1157:   b8 00 00 00 00          mov    $0x0,%eax
    115c:   e8 cf fe ff ff          call   1030 <inci@plt>

They both correspond to C code:

++i;

According to the assembly, it seems that the linker has already decided the run-time address of i, because it is using a PC-relative address to reference it directly, rather than using GOT. However, as far as I know, the shared library is only loaded into memory when the program uses it loads. Thus, the executable main should have no knowledge about the address of i at link time. Then, how does the linker determine that i is located at 0x4020?

Also what does the comment i@@Base mean?

I have two theories, but I am not entirely sure, either these are not the same variable (15 is not 4020), or and this is more likely, the shared library does need to know "where stuff is", even though it will be loaded dynamically, it still has to know where e.g., the next instruction is, so it uses offsets. Note that this can also depend on the OS, which one are you using? P.s., your first assembly snipet, you say main. , that should be main.o I presume? — Plegeus, Feb 04 '23 at 10:57
@Plegeus Yes, the first disassemble snippet is from main.o. About your explanation, I think shared libraries reference global data objects and functions through GOT and PLT, which are also resolved at load time. The assembly in main.o and main looks like that the reference to i is resolved at link time, and that makes no sense to me since the address of i is unknown at link time. — drcxd, Feb 04 '23 at 11:39
It is possible that the compiler can see that you only do one increment, and then do nothing with it anymore. The compiler may be able to "reason" that it is not worth the effort figuring out where to put the actual data, since you will not be doing anything with that executable and that integer i anymore. Compilers these days are very clever and really try to minimise the amount of instructions needed to execute. I suggest you add a function both in the executable and the library that actually make use of this variable i, again, C always depends on the platform, so I am not entirely sure. — Plegeus, Feb 04 '23 at 11:48
@Plegeus The compiler cannot possibly know what other TUs do. — n. m. could be an AI, Feb 04 '23 at 12:14
@n.m.: It is theoretically possible in this case, although I do not believe common compilers implement it: In a hosted implementation, `main` is the initial entry point of the C program, and the compiler can see that `main` does not call any other routines, and therefore no routines in any other translation units will execute, so they will not modify `i`. While there may be automatic initialization code due to C++ or other features, the behavior of those is not defined by the C standard, so a conforming C implementation may ignore it. — Eric Postpischil, Feb 04 '23 at 12:44
@EricPostpischil We are talking about an implementation that is aware of shared libraries. A compiler cannot possibly apply this reasoning in presence of shared libraries if it wants to live on the market for longer than 10 minutes. — n. m. could be an AI, Feb 04 '23 at 13:01
@n.m.: As I stated, common compilers do not implement this; it is theoretically possible to do so while conforming to the C standard, hence the statement “The compiler cannot possibly know what other TUs do” is false in the context of conforming C implementations. — Eric Postpischil, Feb 04 '23 at 13:23
The compiler knows what code it is currently compiling, I do not know how exactly, but I do know that compilers are very clever these days, it is entirely possible that the compiler notices that i is only used once, hence my proposal to put it in more places, by the assembly given I think the compiler just tries to increment (and does so) one value, but doesn't bother to do anything else with it since that is not required by the program... — Plegeus, Feb 04 '23 at 13:26
I have updated the source code and the disassembles, invoking a routine defined in the shared library. The compiler/linker gives the same result. — drcxd, Feb 04 '23 at 13:33

Employed Russian · Accepted Answer · 2023-02-05T16:31:29.623

According to the assembly, it seems that the linker has already decided the run-time address of i, because it is using a PC-relative address to reference it directly, rather than using GOT.

Correct.

However, as far as I know, the shared library is only loaded into memory when the program uses it loads.

Correct, except the i variable in the shared library is never used, and so its address doesn't matter.

What happens here is described pretty well in Solaris documentation:

Suppose the link-editor is used to create a dynamic executable, and a reference to a data item is found to reside in one of the dependent shared objects. Space is allocated in the dynamic executable's .bss, equivalent in size to the data item found in the shared object. This space is also assigned the same symbolic name as defined in the shared object. Along with this data allocation, the link-editor generates a special copy relocation record that instructs the runtime linker to copy the data from the shared object to the allocated space within the dynamic executable.

Because the symbol assigned to this space is global, it is used to satisfy any references from any shared objects. The dynamic executable inherits the data item. Any other objects within the process that make reference to this item are bound to this copy. The original data from which the copy is made effectively becomes unused.

You can observe this using readelf -Ws main:

Symbol table '.dynsym' contains 5 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
...
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND inci
     4: 0000000000404024     4 OBJECT  GLOBAL DEFAULT   25 i

Note that the inci() is undefined (it's defined in libother.so), but i is defined in the main as a global symbol, and readelf -Wr main:

Relocation section '.rela.dyn' at offset 0x4d8 contains 3 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
...
0000000000404024  0000000400000005 R_X86_64_COPY          0000000000404024 i + 0

Relocation section '.rela.plt' at offset 0x520 contains 1 entry:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000404018  0000000200000007 R_X86_64_JUMP_SLOT     0000000000000000 inci + 0

How does linker resolve references to data object in shared libraries at link time?

1 Answers1