Beginner's guide to linkers

1. Beginner's Guide to Linkers
Pinkus.Chang

2. Outline
• Question : compiler error
• Naming of Parts: What's in a C File
• Dissecting An Object File
• Adding C++ to the picture
• What’s the linker does part1
• What’s the linker does part2
• Adding C++ to the picture

3. Question : compiler error
A typical example of what triggers this explanation is when I help
someone who has a link error like:
Ans: ‘Almost certainly missing extern "C"'

4. Naming of Parts: What's in a C File
• Declaration vs Definition
• 不直觀的特殊情況
– 用 static 修飾的局部變量實際上是全局變量，因為雖然它們僅在某個函
數中可見，但其生命週期存在於整個程序中
– 同樣，用 static 修飾的全局變量也被認為是全局的，儘管它們只能由它
們所在的文件內的函數訪問
• Compiler
– 編譯器都只允許使用已經聲明（declaration）過的變量和函數，程序員對
編譯器的承諾：向它確保這個變量或函數已經在程序中的別處定義過了
• Linker
– 兌現這一承諾
– 編譯器會留個空白（blank），這個「空白」（我們也稱之為「引用」
（reference））擁有與之相關聯的一個名字，但該名字對應的值還尚未可
知。

5. 新夥伴 c_parts.c

6. Code
Data
Global Local Dynamic
Initialized Uninitialized Initialized Uninitialized
Declaration
(extern)int
fn_a()
extern int z_global; N/A N/A N/A
Definition
static int fn_b()
int fn_c()
int x_global_init= 1;
(All scope)
static int y_global_init= 2;
(at file scope)
int x_global_unninit;
(All scope)
static int y_global_init= 2;
(at file scope)
int y_local_init= 1;
(at function scope)
int y_local_uninit;
(at function scope)
(int* p =
malloc(sizeof(int));)
要process起來才會有橘色部分

7. Dissecting An Object File : nm
U: 該類型表示未定義的引用（undefined reference），即我們前文所提及的「空白」
（blanks）。對於示例中的目標文件，共有兩個未定義類型：「fn_a」 和 「z_global」。（有
些 nm 的版本還可能包括 section（譯註：即宏彙編中的區，後文直接使用section而不另作中文
翻譯）的名字，section的內容通常為 *UND* 或 UNDEF）
t/T: 該類型指明了代碼定義的位置。t 和 T 用於區分該函數是定義在文件內部（t）還是定義
在文件外部（T）——例如，用於表明某函數是否聲明為 static。同樣的
，有些系統包括 section ，內容形如.text
d/D: 該類型表明當前變量是一個已初始化的變量，d 指明這是一個局部變量，D 則表示全局
變量。如果存在 section ，則內容形如 .data
b/B: 對於非初始化的變量，我們用 b 來表示該變量是靜態（static）或是局部的（local），否
則，用 B 或 C 來表示。這時 section 的內容可能為.bss 或者 *COM*

8. What The Linker Does : Part 1

9. 增加新夥伴 main.c

10. Linker main.c and c_parts.c
main.c
c_parts.c
on a UNIX system, the linker is typically invoked with ld

11. nm main.exe
「未定義的引用」都已消失
多複雜的細節，看上去很混亂
=>劃線開頭的內容都過濾掉

12. Duplicate Symbols
• C++
– one definition rule
• 即鏈接階段，一個符號有且只能定義一次
• C
– 任何的函數或者已經初始化的全局變量，都有且只能有一次定義即鏈接階段，一個符號
有且只能定義一次
– But…未初始化的全局變量的定義可以看成是一種臨時性定義（a tentative definition）
• Another language
– Fortran : Linker 還得對付除 C/C++ 以外的其它語言
– one definition rule 並不適用
– As a result, it's actually quite common for UNIX linkers not to complain about duplicate
definitions of symbols—at least, not when the duplicate symbol is an uninitialized global
variable (this is sometimes known as the "relaxed ref/def model" of linking). If this worries you
(and it probably should), check the documentation for your compiler linker—there may well
be a --work-properly option that tightens up the behavior. For example, for the GNU toolchain
the -fno-common option to the compiler forces it to put uninitialized variables into the BSS
segment rather than generating these common blocks.

13. What The Operating System Does
1.把code segment(text segment) 從 disk 搬到 memory
------------------------------------------------------
2.把data segment (initial global variable )搬入
3.把bss segment( uninitialized global variable) 搬進去 但不用copy其值 預設都是0
------------------------------------------------------
Local variable 不用linker幫忙 因為他生命週期只在process運行時
1.Local variable stack
2.Malloc等等變數  heap
3.Heap stack 撞再一起，就是滿了
123
1 2

14. The size command didn't list a stack or heap segment for hello_world
or hello_world.o. Why do you think that is?
Review memory-layout
1.compiler and linker : gcc
2.Loader : exec
Disk file
Process memory

15. What The Linker Does: Part 2

16. Static libraries
1.Command : ar
2.libXXX.a
3.gcc –llibXXX.a
4.未解決符號表
it builds a list of the symbols it hasn't been able to resolve yet.
When all of the explicitly specified objects are done with, the linker now has
another place to look for the symbols that are left on this
5.Libraries的處理順序，相依性。
linker按命令行從左到右的順序進行處理，只有前一個庫處理結束了，才會繼續
處理下一個庫。換句話說，如果後一個庫中導入的目標文件依賴於前一個庫中的
某個符號，那麼鏈接器將無法進行自動關聯。

17. File a.o b.o libx.a liby.a
Object a.o b.o x1.o x2.ox3.o y1.o y2.o y3.o
Definitions
a1,
a2,
a3
b1,
b2
x11,
x12,
x13
x21,
x22,
x23
X31,
x32
y11,
y12
y21,
y22
y31, y32
Undefined
references
b2,
x12
a3,
y22
x23,
y12
y11 y21 x31
gcc main.exe –lx –ly a.o b.o
Step1: we can get b2 a3 ,but we still lose x12 y22
Step2: try to find x12 y22 in libx.a ,get x12 on x1.o
=> leak y22,x23,y12
Step3: try to find x23 and y12 because linker is still dealing with libx.a
=> leak y22 y12 y11
Setp4: try to find y21 y12 y11 on liby.a ,不過由於 y22 的存在，y2.o 無論如何都必須導入
=> finish

18. File a.o b.o libx.a liby.a
Object a.o b.o x1.o x2.ox3.o y1.o y2.o y3.o
Definitions
a1,
a2,
a3
b1,
b2
x11,
x12,
x13
x21,
x22,
x23
X31,
x32
y11,
y12
y21,
y22
y31, y32
Undefined
references
b2,
x12
a3,
y22
y32
x23,
y12
y11 y21 x31
Step5.y32 can find on liby.a , but ……….
1.x31 has been linked pervious time(libx.a) by this stage the linker has already
finished with libx.a and would not find the definition (in x3.o) for this symbo
Cyclic dependency
We don’t load x3.o previous time.

19. Shared libraries
• Static libraries 缺點
– 1.浪費空間，所有代碼都要copy同一份
– 2.修改某個lib bug後，要全部重新link，才可已拿到修正後的code
• Shared libraries
– IOU(我欠你)
• 等到process真正在運行的時候，才對這TAG處理
• 所以linker 發現 so 並不會把symbol包到exe 內，而是將symbol與其對應的libraries 記錄下來。
– Small linker: ld.so
• Before program counter come to int main()
• 負責檢查貼過標籤的內容，並完成鏈接的最後一個步驟：導入庫裡的代碼，並將所有符號都關
聯在一起
– the granularity of the link
• 如果程序中只引用了共享庫裡的某個符號（比如，只使用了 libc.so 庫中的 printf），那麼整個共
享庫都將映射到程序地址空間中，這與靜態庫的行為完全不同，靜態庫中只會導入與該符號相
關的那個目標文件。

20. Put another way….
• shared library
=>can resolve to references between objects in the same library getting resolved.
因為整個so 內含的.o都會被放入，不會直有用到才放的問題
File a.o b.o libx.so liby.so
Object a.o b.o x1.o x2.ox3.o y1.o y2.o y3.o
Definitions
a1,
a2,
a3
b1,
b2
x11,
x12,
x13
x21,
x22,
x23
X31,
x32
y11,
y12
y21,
y22
y31, y32
Undefined
references
b2,
x12
a3,
y22
y32
x23,
y12
y11 y21 x31
x3.o can be linked when ld.so working

21. Command ldd
• ldd
– shows the set of shared libraries that an executable (or a
shared library) depends on
– LD_LIBRARY_PATH
• Typically, the loader looks for libraries in the list of directories held
in the LD_LIBRARY_PATH environment variable.

22. Adding C++ To The Picture
1. Function Overloading & Name Mangling
2. Initialization of Statics
3. Templates
4. Dynamically Loaded Libraries

23. Function Overloading & Name Mangling
1.Good friends: nm
2.ii:integer ff: float dd:double
The mangled names : nm --demangle

24. need to add extern C
The C++ code is actually looking for something like "_Z7findmaxii" but only
finding "findmax"
By the way, note that an extern "C" linkage
declaration is ignored for member functions

25. Initialization of Statics
For this code, the (demangled) output of nm gives:
Class
1.Constructor
2.W:weak symbols
3.所有這些全局對象的構造函數的調用順序並未定
義——因此，這完全取決於鏈接器的實現
way1: the sane way
way2: the Sun way : 看不懂 GG, PASS~~

26. Templates
Way1: the sane way
對於第一種方法，即將每個實例函數代碼
展開，每個目標文件中都會包含它所調用
的所有模板函數的代碼，以上文的 C++ 文
件為例，目標文件內容如下：
目標函數將這兩個函數的定義標記成「弱
符號」（weak symbos），這表示當鏈接器
最終生成可執行程序時，將只留下所有重
複定義的其中之一，剩餘的定義都將棄之
不用

27. Dynamically Loaded Libraries
• 最終的鏈接操作可以延遲到程序真正運行的時
刻
• dlopen and dlsym
• dlopen兩種選擇
– 解決導入庫的所有未定義符號（RTLD_NOW）: 長
– 按遇到的順序一個個解決未定義符號
（RTLD_LAZY）: 快，看有可能在process運作中，發
現undefined symbol 導致process crash

28. Conclusion
• C++ compiler 還有很多東西看不懂
EX:動態載入與C++特性的交互
Interaction with C++ Features
• Shared libraries with GCC on Linux
– http://cprogramming.com/
– 這篇不錯，寫得很入門。

29. 常見command
# All information
readelf -a
# check shared libraries
readelf –a *.so | grep Shared
# GCC version
readelf -p .comment
# CPU version
readelf -h
# module version
readelf -p .mmodule_version
# check symbol on execute file
nm
# check memory layout after linker
size
# Linking with a shared library
ld
# shows the set of shared libraries that an executable (or a
shared library) depends on
ldd
# generate static libraries
ar
# telling GCC where to find the shared library
gcc -L/home/username/foo -Wall -o test main.c -lfoo
'Note that the -lfoo option is not looking for foo.o, but libfoo.so'
# header
gcc -I

30. addr2line
# addr2line
PC: /lib/libc-2.24.so [0x74a65bac]
LR: /usr/lib/libadaptor.so.0.1.0 [0x759becd8]
754c8000-75a9a000 r-xp 00000000 b3:1f 146 /usr/lib/libkadaptor.so.0.1.0
75a9a000-75aaa000 ---p 005d2000 b3:1f 146 /usr/lib/libkadaptor.so.0.1.0
75aaa000-75b89000 rw-p 005d2000 b3:1f 146 /usr/lib/libkadaptor.so.0.1.0
>>> hex(0x759becd8-0x754c8000)
'0x4f6cd8'
$ addr2line -a -f -e ./libkadaptor.so 0x4f6cd8

31. Reference
• http://www.lurklurk.org/linkers/linkers.html
• http://blog.jobbole.com/96225/
• http://www.geeksforgeeks.org/memory-
layout-of-c-program/
• http://www.cprogramming.com/tutorial/shar
ed-libraries-linux-gcc.html

32. More Detail
• John Levine, Linkers and Loaders: contains lots and lots of information about the details of linkers
and loaders work, including all the things I've skipped here. There also appears to be an online
version of it (or an early draft of it) here
• Excellent link on the Mach-O format for binaries on Mac OS X [Added 27-Mar-06]
• Peter Van Der Linden, Expert C Programming: excellent book which includes more information
about how C codetransforms into a running program than any other C text I've encountered
• Scott Meyers, More Effective C++: Item 34 covers the pitfalls of combining C and C++ in the same
program (whether linker-related or not).
• Bjarne Stroustrup, The Design and Evolution of C++: section 11.3 discusses linkage in C++ and how
it came about
• Margaret A. Ellis & Bjarne Stroustrup, The Annotated C++ Reference Manual: section 7.2c describes
one particular name mangling scheme
• ELF format reference [PDF]
• Two interesting articles on creating tiny Linux executables and a minimal Hello World in particular.
• "How To Write Shared Libraries" [PDF] by Ulrich Drepper has more details on ELF and relocation.