-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathelf.html
2503 lines (2342 loc) · 128 KB
/
elf.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Executable and Linkable Format (ELF)</title>
</head>
<body alink="#FF6600" bgcolor="#000000" link="#00FFFF" text="#EEEEEE" vlink="#00FFFF">
<p>This page is a copy of the <a href="https://web.archive.org/web/20201202024834/https://web.archive.org/web/20120922073347/http://www.acsu.buffalo.edu/~charngda/elf.html">Archive.org</a>
copy of the now no longer availabel <a href="https://web.archive.org/web/20201202024834/http://www.acsu.buffalo.edu/~charngda/elf.html">http://www.acsu.buffalo.edu/~charngda/elf.html</a>.
It is kept here online as a reference only.</p>
<hr>
<h2>Acronyms relevant to Executable and Linkable Format (ELF)</h2>
<table border="">
<tbody><tr><td><a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/Application_binary_interface">ABI</a></td><td>Application binary interface</td></tr>
<tr><td><a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/A.out">a.out</a></td><td>Assembler output file format</td></tr>
<tr><td><a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/.bss">BSS</a></td><td>Block started by symbol. The uninitialized data segment containing statically-allocated variables.</td></tr>
<tr><td><a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/COFF">COFF</a></td><td>Common object file format</td></tr>
<tr><td>DTV</td><td>Dynamic thread vector (for TLS)</td></tr>
<tr><td><a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/DWARF">DWARF</a></td><td>A standardized debugging data format</td></tr>
<tr><td>GD</td><td>Global Dynamic (dynamic TLS) One of the <a href="https://web.archive.org/web/20201202024834/http://download.oracle.com/docs/cd/E19963-01/html/819-0690/chapter8-1.html">Thread-Local Storage access models</a>.</td></tr>
<tr><td>GOT</td><td>Global offset table</td></tr>
<tr><td>IE</td><td>Initial Executable (static TLS with assigned offsets) One of the <a href="https://web.archive.org/web/20201202024834/http://download.oracle.com/docs/cd/E19963-01/html/819-0690/chapter8-1.html">Thread-Local Storage access models</a>.</td></tr>
<tr><td>LD</td><td>Local Dynamic (dynamic TLS of local symbols) One of the <a href="https://web.archive.org/web/20201202024834/http://download.oracle.com/docs/cd/E19963-01/html/819-0690/chapter8-1.html">Thread-Local Storage access models</a>.</td></tr>
<tr><td>LE</td><td>Local Executable (static TLS) One of the <a href="https://web.archive.org/web/20201202024834/http://download.oracle.com/docs/cd/E19963-01/html/819-0690/chapter8-1.html">Thread-Local Storage access models</a>.</td></tr>
<tr><td><a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/Mach-O">Mach-O</a></td><td>Mach object file format</td></tr>
<tr><td>PC</td><td>Program counter. On x86, this is the same as IP (Instruction Pointer) register.</td></tr>
<tr><td><a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/Portable_Executable">PE</a></td><td>Portable executable</td></tr>
<tr><td>PHT</td><td>Program header table</td></tr>
<tr><td><a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/Position_independent_code">PIC</a></td><td>Position independent code</td></tr>
<tr><td><a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/Position_independent_code">PIE</a></td><td>Position independent executable</td></tr>
<tr><td>PLT</td><td>Procedure linkage table</td></tr>
<tr><td>REL<br>RELA</td><td>Relocation</td></tr>
<tr><td>RVA</td><td>Relative virtual address</td></tr>
<tr><td>SHF</td><td>Section header flag</td></tr>
<tr><td>SHT</td><td>Section header table</td></tr>
<tr><td>SO</td><td>Shared object (another name for dynamic link library)</td></tr>
<tr><td>VMA</td><td>Virtual memory area/address</td></tr>
</tbody></table>
<h2>Useful books and references</h2>
<a href="https://web.archive.org/web/20201202024834/http://manpages.courier-mta.org/htmlman5/elf.5.html">ELF man page</a><a>
</a><p><a>
</a><a href="https://web.archive.org/web/20201202024834/http://www.sco.com/developers/gabi/latest/contents.html">System V Application Binary Interface</a><a>
</a></p><p><a>
</a><a href="https://web.archive.org/web/20201202024834/http://www.x86-64.org/documentation/abi.pdf">AMD64 System V Application Binary Interface</a>
</p><p>
<a href="https://web.archive.org/web/20201202024834/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/function-calling-conventions.html">The gen on function calling conventions</a>
</p><p>
Section II of <a href="https://web.archive.org/web/20201202024834/http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/book1.html">Linux Standard Base 4.0 Core Specification</a>
</p><p>
<i>Self-Service Linux: Mastering the Art of Problem Determination</i> by Mark Wilding and Dan Behman
</p><p>
<a href="https://web.archive.org/web/20201202024834/http://download.oracle.com/docs/cd/E19963-01/html/819-0690/">Solaris Linker and Libraries Guide</a>
</p><p>
<a href="https://web.archive.org/web/20201202024834/http://www.iecc.com/linker">Linkers and Loaders</a> by John Levine
</p><p>
<a href="https://web.archive.org/web/20201202024834/http://s.eresi-project.org/inc/articles/elf-rtld.txt">Understanding Linux ELF RTLD internals</a> by mayhem (this article gives
you an idea how the runtime linker <tt>ld.so</tt> works)
</p><p>
<a href="https://web.archive.org/web/20201202024834/http://manpages.courier-mta.org/htmlman8/ld.so.8.html"><tt>ld.so</tt> man page</a>
</p><p>
<a href="https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/Prelink">Prelink</a> by Jakub Jelinek (and <a href="https://web.archive.org/web/20201202024834/http://linux.die.net/man/8/prelink">prelink man page</a>)
</p><h2>Executable and Linkable Format</h2>
An ELF executable binary contains at least two kinds of headers: ELF file header
(see <tt>struct Elf32_Ehdr</tt>/<tt>struct Elf64_Ehdr</tt> in <tt><a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/elf.h">/usr/include/elf.h</a></tt>)
and one or more Program Headers (see <tt>struct Elf32_Phdr</tt>/<tt>struct Elf64_Phdr</tt> in <tt><a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/elf.h">/usr/include/elf.h</a></tt>)
<p>
Usually there is another kind of header called Section Header, which describe
attributes of an ELF section (e.g. <tt>.text</tt>, <tt>.data</tt>,
<tt>.bss</tt>, etc) The Section Header is
described by <tt>struct Elf32_Shdr</tt>/<tt>struct Elf64_Shdr</tt> in <tt><a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/elf.h">/usr/include/elf.h</a></tt>
</p><p>
The Program Headers are used during execution (ELF's "<b>execution view</b>"); it tells the kernel or the runtime linker
<tt>ld.so</tt> what to load into memory and how to find dynamic linking information.
</p><p>
The Section Headers are used during compile-time linking (ELF's "<b>linking view</b>"); it tells the link editor <tt>ld</tt>
how to resolve symbols, and how to group similar byte streams from different ELF binary
objects.
</p><p>
Conceptually, the two ELF's "views" are as follows (borrowed from Shaun Clowes's <i>Fixing/Making Holes in Binaries</i> slides):
</p><pre> +-----------------+
+----| ELF File Header |----+
| +-----------------+ |
v v
+-----------------+ +-----------------+
| Program Headers | | Section Headers |
+-----------------+ +-----------------+
|| ||
|| ||
|| ||
|| +------------------------+ ||
+--> | Contents (Byte Stream) |<--+
+------------------------+
</pre>
<p>
In reality, the layout of a typical ELF executable binary on a disk file is like this:
</p><pre> +-------------------------------+
| ELF File Header |
+-------------------------------+
| Program Header for segment #1 |
+-------------------------------+
| Program Header for segment #2 |
+-------------------------------+
| ... |
+-------------------------------+
| Contents (Byte Stream) |
| ... |
+-------------------------------+
| Section Header for section #1 |
+-------------------------------+
| Section Header for section #2 |
+-------------------------------+
| ... |
+-------------------------------+
| ".shstrtab" section |
+-------------------------------+
| ".symtab" section |
+-------------------------------+
| ".strtab" section |
+-------------------------------+
</pre>
The ELF File Header contains the file offsets of the first Program Header,
the first Section Header, and <tt>.shstrtab</tt> section which contains
the section names (a series of NULL-terminated strings)
<p>
The ELF File Header also contains the number of Program Headers
and the number of Section Headers.
</p><p>
Each Program Header describes a "segment": It contains the permissions (Readable, Writeable, or Executable)
, offset of the "segment" (which is just a byte stream) into the file, and the size of the
"segment". The following table shows the purposes of special segments.
Some information
can be found in GNU Binutil's source file <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=binutils.git;a=blob_plain;f=include/elf/common.h"><tt>include/elf/common.h</tt></a>:
</p><p>
<table border="">
<tbody><tr>
<th>ELF Segment</th>
<th>Purpose</th>
</tr>
<tr>
<td><tt>DYNAMIC</tt></td>
<td>For dynamic binaries, this segment hold dynamic linking information and is usually
the same as <tt>.dynamic</tt> section in ELF's linking view. See paragraph below.
</td>
</tr>
<tr>
<td><tt>GNU_EH_FRAME</tt></td>
<td>Frame unwind information (EH = Exception Handling). This segment is usually the same as <tt>.eh_frame_hdr</tt> section in ELF's linking view.
</td>
</tr>
<tr>
<td><tt>GNU_RELRO</tt></td>
<td>This segment indicates the memory region which should be made Read-Only after relocation is done.
This segment usually appears in a dynamic link library and it
contains <tt>.ctors</tt>, <tt>.dtors</tt>, <tt>.dynamic</tt>, <tt>.got</tt>
sections. See paragraph below.
</td>
</tr>
<tr>
<td><tt>GNU_STACK</tt></td>
<td>The permission flag of this segment indicates whether the
<a href="https://web.archive.org/web/20201202024834/http://www.gentoo.org/proj/en/hardened/gnu-stack.xml">stack is executable or not</a>.
This segment does not have any content; it is just an indicator.
</td>
</tr>
<tr>
<td><tt>INTERP</tt></td>
<td>For dynamic binaries, this holds the full pathname of runtime linker <tt>ld.so</tt><p>
This segement is the same as <tt>.interp</tt> section in ELF's linking view.
</p></td>
</tr>
<tr>
<td><tt>LOAD</tt></td>
<td><b>Loadable program segment. Only segments of this type are loaded into memory during execution.</b></td>
</tr>
<tr>
<td><tt>NOTE</tt></td>
<td>Auxiliary information.<p>For core dumps, this segment contains the status of the process (when the core dump is created),
such as the signal (the process received and caused it to dump core), pending & held signals,
process ID, parent process ID, user ID, nice value,
cumulative user & system time, values of registers (including the program counter!)</p><p>For more info, see
<tt>struct elf_prstatus</tt> and <tt>struct elf_prpsinfo</tt> in Linux kernel source file
<a href="https://web.archive.org/web/20201202024834/http://lxr.linux.no/linux/include/linux/elfcore.h"><tt>include/linux/elfcore.h</tt></a>
and <tt>struct user_regs_struct</tt> in
<a href="https://web.archive.org/web/20201202024834/http://lxr.linux.no/linux/arch/x86/include/asm/user_64.h"><tt>arch/x86/include/asm/user_64.h</tt></a></p></td>
</tr>
<tr>
<td><tt>TLS</tt></td>
<td>Thread-Local Storage</td>
</tr>
</tbody></table>
</p><p>
Likewise, each Section Header contains the file offset of its corresponding "content"
and the size of the "content".
The following table shows the purposes of some special sections. Most information
here comes from <a href="https://web.archive.org/web/20201202024834/http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/specialsections.html">LSB specification</a>.
Some information can be found in GNU Binutil's source file
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=binutils.git;a=blob_plain;f=bfd/elf.c"><tt>bfd/elf.c</tt></a> (look for
<tt>bfd_elf_special_section</tt>)
and <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=binutils.git;a=blob_plain;f=bfd/elflink.c"><tt>bfd/elflink.c</tt></a> (look for
double-quoted section names such as <tt>".got.plt"</tt>)
</p><p>
<table border="">
<tbody><tr>
<th>ELF Section</th>
<th>Purpose</th>
</tr>
<tr>
<td><tt>.bss</tt></td>
<td>Uninitialized global data ("Block Started by Symbol").
<p>Depending on the compilers, uninitialized global variables could
be stored in a nameness section called <tt>COMMON</tt> (named after
Fortran 77's "common blocks".) To wit, consider
the following code:
</p><pre> int globalVar;
static int globalStaticVar;
void dummy() {
static int localStaticVar;
}
</pre>
Compile with <tt>gcc -c</tt>, then on x86_64, the resulting object file has the
following structure:
<pre> $ objdump -t foo.o
SYMBOL TABLE:
....
0000000000000000 l O .bss 0000000000000004 globalStaticVar
0000000000000004 l O .bss 0000000000000004 localStaticVar.1619
....
0000000000000004 O *COM* 0000000000000004 globalVar
</pre>
so only the file-scope and local-scope global variables are in
the <tt>.bss</tt> section.
<p>
If one wants <tt>globalVar</tt> to reside in the <tt>.bss</tt> section,
use the <font color="LightGreen"><tt>-fno-common</tt></font>
compiler command-line option. Using <font color="LightGreen"><tt>-fno-common</tt></font>
is encouraged, as the following example shows:
</p><pre> $ cat foo.c
int globalVar;
$ cat bar.c
double globalVar;
int main(){}
$ gcc foo.c bar.c
</pre>
Not only there is no error message about redefinition of the same symbol
in both source files (notice we did not use the <tt>extern</tt> keyword here),
there is no complaint about their different data
types and sizes either. However, if one uses <font color="LightGreen"><tt>-fno-common</tt></font>,
the compiler will complain:
<pre> /tmp/ccM71JR7.o:(.bss+0x0): <font color="Red">multiple definition</font> of `globalVar'
/tmp/ccIbS5MO.o:(.bss+0x0): first defined here
ld: Warning: <font color="Red">size of symbol</font> `globalVar' changed from 8 in /tmp/ccIbS5MO.o to 4 in /tmp/ccM71JR7.o
</pre>
</td>
</tr>
<tr>
<td><tt>.comment</tt></td>
<td>A series of NULL-terminated strings containing compiler information.</td>
</tr>
<tr>
<td><tt>.ctors</tt></td>
<td><b>Pointers</b> to functions which are marked as
<tt>__attribute__ ((constructor))</tt> as well as static C++ objects' constructors.
They will be used by <tt>__libc_global_ctors</tt> function.<p>
See paragraphs below.
</p></td>
</tr>
<tr>
<td><tt>.data</tt></td>
<td>Initialized data.</td>
</tr>
<tr>
<td><tt>.data.rel.ro</tt></td>
<td>Similar to <tt>.data</tt> section, but this section
should be made Read-Only after relocation is done.
</td>
</tr>
<tr>
<td><tt>.debug_XXX</tt></td>
<td>Debugging information (for the programs which are compiled with <tt>-g</tt> option)
which is in the DWARF 2.0 format.
<p>
See <a href="https://web.archive.org/web/20201202024834/http://dwarfstd.org/">here</a> for DWARF debugging format.
</p></td>
</tr>
<tr>
<td><tt>.dtors</tt></td>
<td><b>Pointers</b> to functions which are marked as
<tt>__attribute__ ((destructor))</tt> as well as static C++ objects' destructors.
<p>
See paragraphs below.
</p></td>
</tr>
<tr>
<td><tt>.dynamic</tt></td>
<td>For dynamic binaries, this section holds dynamic linking information used by <tt>ld.so</tt>.
See paragraphs below.</td>
</tr>
<tr>
<td><tt>.dynstr</tt></td>
<td>NULL-terminated strings of names of symbols in <tt>.dynsym</tt> section.
<p>One can use commands such as <tt>readelf -p .dynstr a.out</tt> to see these strings.
</p></td>
</tr>
<tr>
<td><tt>.dynsym</tt></td>
<td><b>Runtime</b>/Dynamic symbol table. For dynamic binaries, this section is the symbol table of
globally visible symbols. For example, if a dynamic link library wants to export
its symbols, these symbols will be stored here. On the other hand, if
a dynamic executable binary uses symbols from a dynamic link library,
then these symbols are stored here too.
<p>
The symbol names (as NULL-terminated strings) are stored in <tt>.dynstr</tt> section.
</p></td>
</tr>
<tr>
<td><tt>.eh_frame</tt><br><tt>.eh_frame_hdr</tt></td>
<td>Frame unwind information (EH = Exception Handling).
<p>
See <a href="https://web.archive.org/web/20201202024834/http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html">here</a>
for details.
</p><p>To see the content of <tt>.eh_frame</tt> section, use
</p><pre>readelf --debug-dump=frames-interp a.out</pre>
</td>
</tr>
<tr>
<td><tt>.fini</tt></td>
<td>Code which will be executed when program exits normally. See paragraphs below.</td>
</tr>
<tr>
<td><tt>.fini_array</tt></td>
<td><b>Pointers</b> to functions which will be executed when program exits normally. See paragraphs below.</td>
</tr>
<tr>
<td><tt>.GCC.command.line</tt></td>
<td>A series of NULL-terminated strings containing
GCC command-line (that is used to compile the code) options.<p>This feature is supported since GCC 4.5
and the program must be compiled with <tt>-frecord-gcc-switches</tt> option.
</p></td>
</tr>
<tr>
<td><tt>.gnu.hash</tt></td>
<td>GNU's extension to hash table for symbols.<p>
See <a href="https://web.archive.org/web/20201202024834/http://blogs.sun.com/ali/entry/gnu_hash_elf_sections">here</a> for its structure and the hash algorithm.
</p><p>
The link editor <tt>ld</tt> calls <tt>bfd_elf_gnu_hash</tt> in
in GNU Binutil's source file <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=binutils.git;a=blob_plain;f=bfd/elf.c"><tt>bfd/elf.c</tt></a>
to compute the hash value.
</p><p>
The runtime linker <tt>ld.so</tt> calls <tt>do_lookup_x</tt> in
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-lookup.c"><tt>elf/dl-lookup.c</tt></a>
to do the symbol look-up. The hash computing function here is <tt>dl_new_hash</tt>.
</p></td>
</tr>
<tr>
<td><tt>.gnu.linkonceXXX</tt></td>
<td>GNU's extension. It means only a single copy of the section will be used in linking.
This is used to by g++. g++ will emit each template expansion in its own section.
The symbols will be defined as weak, so that multiple definitions
are permitted.
</td>
</tr>
<tr>
<td><tt>.gnu.version</tt></td>
<td>Versions of symbols.
<p>See <a href="https://web.archive.org/web/20201202024834/http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/symversion.html">here</a>,
<a href="https://web.archive.org/web/20201202024834/http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/version.html">here</a>,
<a href="https://web.archive.org/web/20201202024834/http://download.oracle.com/docs/cd/E19963-01/html/819-0690/appendixb-45356.html">here</a>,
and
<a href="https://web.archive.org/web/20201202024834/http://people.redhat.com/drepper/symbol-versioning">here</a>
for details of symbol versioning.
</p></td>
</tr>
<tr>
<td><tt>.gnu.version_d</tt></td>
<td>Version definitions of symbols.</td>
</tr>
<tr>
<td><tt>.gnu.version_r</tt></td>
<td>Version references (version needs) of symbols.</td>
</tr>
<tr>
<td><tt>.got</tt></td>
<td>For dynamic binaries, this Global Offset Table holds the addresses of variables which are
relocated upon loading. See paragraphs below.
</td>
</tr>
<tr>
<td><tt>.got.plt</tt></td>
<td>For dynamic binaries, this Global Offset Table holds the addresses of functions in dynamic libraries.
They are used by trampoline code in <tt>.plt</tt> section.
If <tt>.got.plt</tt> section is present, it contains at least three entries, which
have special meanings. See paragraphs below.
</td>
</tr>
<tr>
<td><tt>.hash</tt></td>
<td>Hash table for symbols.<p>
See <a href="https://web.archive.org/web/20201202024834/http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#hash">here</a> for its structure and the hash algorithm.
</p><p>
The link editor <tt>ld</tt> calls <tt>bfd_elf_hash</tt> in
in GNU Binutil's source file <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=binutils.git;a=blob_plain;f=bfd/elf.c"><tt>bfd/elf.c</tt></a>
to compute the hash value.
</p><p>
The runtime linker <tt>ld.so</tt> calls <tt>do_lookup_x</tt> in
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-lookup.c"><tt>elf/dl-lookup.c</tt></a>
to do the symbol look-up. The hash computing function here is <tt>_dl_elf_hash</tt>.
</p></td>
</tr>
<tr>
<td><tt>.init</tt></td>
<td>Code which will be executed when program initializes. See paragraphs below.</td>
</tr>
<tr>
<td><tt>.init_array</tt></td>
<td><b>Pointers</b> to functions which will be executed when program starts. See paragraphs below.</td>
</tr>
<tr>
<td><tt>.interp</tt></td>
<td>For dynamic binaries, this holds the full pathname of runtime linker <tt>ld.so</tt></td>
</tr>
<tr>
<td><tt>.jcr</tt></td>
<td>Java class registration information.<p>
Like <tt>.ctors</tt> section, it contains a list of addresses
which will be used by <tt>_Jv_RegisterClasses</tt> function
in CRT (C Runtime) startup files (see <a href="https://web.archive.org/web/20201202024834/http://gcc.gnu.org/viewcvs/trunk/gcc/crtstuff.c?view=markup"><tt>gcc/crtstuff.c</tt></a>
in GCC's source tree)
</p></td>
</tr>
<tr>
<td><tt>.note.ABI-tag</tt></td>
<td>This Linux-specific section is structured as a <a href="https://web.archive.org/web/20201202024834/http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section">note</a>
section in ELF specification. Its content is mandated
<a href="https://web.archive.org/web/20201202024834/http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/noteabitag.html">here</a>.
</td>
</tr>
<tr>
<td><tt>.note.gnu.build-id</tt></td>
<td>A unique build ID. See <a href="https://web.archive.org/web/20201202024834/http://fedoraproject.org/wiki/RolandMcGrath/BuildID">here</a> and
<a href="https://web.archive.org/web/20201202024834/http://fedoraproject.org/wiki/Releases/FeatureBuildId">here</a>
</td>
</tr>
<tr>
<td><tt>.note.GNU-stack</tt></td>
<td>See <a href="https://web.archive.org/web/20201202024834/http://www.airs.com/blog/archives/518">here</a>
</td>
</tr>
<tr>
<td><tt>.nvFatBinSegment</tt></td>
<td>This segment contains information of nVidia's CUDA fat binary container. Its format
is described by <tt>struct __cudaFatCudaBinaryRec</tt> in <tt>__cudaFatFormat.h</tt>
</td>
</tr>
<tr>
<td><tt>.plt</tt></td>
<td>For dynamic binaries, this Procedure Linkage Table holds the trampoline/linkage code. See paragraphs below.</td>
</tr>
<tr>
<td><tt>.preinit_array</tt></td>
<td>Similar to <tt>.init_array</tt> section. See paragraphs below.</td>
</tr>
<tr>
<td><tt>.rela.dyn</tt></td>
<td><b>Runtime</b>/Dynamic relocation table.
<p>
For dynamic binaries, this relocation table holds information of variables which
must be relocated upon loading. Each entry in this table is a
<tt>struct Elf64_Rela</tt> (see <tt><a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/elf.h">/usr/include/elf.h</a></tt>) which
has only three members:
</p><ul>
<li><tt>offset</tt> (the variable's [usually position-independent] virtual memory address
which holds the "patched" value during the relocation process)
</li><li><tt>info</tt> (Index into <tt>.dynsym</tt> section and Relocation Type)
</li><li><tt>addend</tt>
</li></ul>
See paragraphs below for details about runtime relocation.
</td>
</tr>
<tr>
<td><tt>.rela.plt</tt></td>
<td><b>Runtime</b>/Dynamic relocation table.
<p>
This relocation table is similar to the one in <tt>.rela.dyn</tt> section;
the difference is this one is for functions, not variables.
</p><p>The relocation type of entries in this table is
<tt>R_386_JMP_SLOT</tt> or <tt>R_X86_64_JUMP_SLOT</tt> and
the "offset" refers to memory addresses which are
inside <tt>.got.plt</tt> section.
</p><p>Simply put, this table holds information to relocate entries in
<tt>.got.plt</tt> section.
</p></td>
</tr>
<tr>
<td><tt>.rel.text</tt><br><tt>.rela.text</tt></td>
<td><b>Compile-time</b>/Static relocation table.
<p>For programs compiled with <tt>-c</tt> option,
this section provides information to the link editor <tt>ld</tt>
where and how to "patch" executable code in <tt>.text</tt> section.
</p><p>The difference between <tt>.rel.text</tt> and <tt>.rela.text</tt>
is entries in the former does not have <tt>addend</tt> member.
(Compare <tt>struct Elf64_Rel</tt> with <tt>struct Elf64_Rela</tt> in <tt>/usr/include/elf.h</tt>)
Instead, the addend is taken from the memory location
described by <tt>offset</tt> member.
</p><p>
Whether to use <tt>.rel</tt> or <tt>.rela</tt> is platform-dependent.
For x86_32, it is <tt>.rel</tt> and for x86_64, <tt>.rela</tt>
</p></td>
</tr>
<tr>
<td><tt>.rel.XXX</tt><br><tt>.rela.XXX</tt></td>
<td>Compile-time/Static relocation table for other sections. For example,
<tt>.rela.init_array</tt> is the relocation table for <tt>.init_array</tt>
section.
</td>
</tr>
<tr>
<td><tt>.rodata</tt></td>
<td>Read-only data.</td>
</tr>
<tr>
<td><tt>.shstrtab</tt></td>
<td>NULL-terminated strings of section names.
<p>One can use commands such as <tt>readelf -p .shstrtab a.out</tt> to see these strings.
</p></td>
</tr>
<tr>
<td><tt>.strtab</tt></td>
<td>NULL-terminated strings of names of symbols in <tt>.symtab</tt> section.
<p>One can use commands such as <tt>readelf -p .strtab a.out</tt> to see these strings.
</p></td>
</tr>
<tr>
<td><tt>.symtab</tt></td>
<td><b>Compile-time</b>/Static symbol table.
<p>This is the main symbol table used in compile-time linking
or runtime debugging.
</p><p>
The symbol names (as NULL-terminated strings) are stored in <tt>.strtab</tt> section.
</p><p>Both <tt>.symtab</tt> and <tt>.symtab</tt> can be stripped away by the <tt>strip</tt>
command.
</p></td>
</tr>
<tr>
<td><tt>.tbss</tt></td>
<td>Similar to <tt>.bss</tt> section, but for <i>Thread-Local data</i>. See paragraphs below.</td>
</tr>
<tr>
<td><tt>.tdata</tt></td>
<td>Similar to <tt>.data</tt> section, but for <i>Thread-Local data</i>. See paragraphs below.</td>
</tr>
<tr>
<td><tt>.text</tt></td>
<td>User's executable code</td>
</tr>
</tbody></table>
</p><h2>How is an executable binary in Linux being executed ?</h2>
First, the operating system must recognize executable binaries. For example,
<tt>zcat /proc/config.gz | grep <a href="https://web.archive.org/web/20201202024834/http://cateee.net/lkddb/web-lkddb/BINFMT_ELF.html">CONFIG_BINFMT_ELF</a></tt> can show whether the Linux kernel is compiled
to support ELF executable binary format (if <tt>/proc/config.gz</tt> does not exist, try
<tt>/lib/modules/`uname -r`/build/.config</tt>)
<p>
When the shell makes an <tt>execvc</tt> system call to run an executable binary, the Linux kernel responds as
follows (see <a href="https://web.archive.org/web/20201202024834/http://asm.sourceforge.net/articles/startup.html">here</a> and
<a href="https://web.archive.org/web/20201202024834/http://s.eresi-project.org/inc/articles/elf-rtld.txt">here</a> for more details) in sequence:
</p><ol>
<li><a href="https://web.archive.org/web/20201202024834/http://lxr.linux.no/linux/arch/x86/kernel/process.c#L301"><tt>sys_execve</tt></a> function (in <tt>arch/x86/kernel/process.c</tt>) handles the <tt>execvc</tt> system call
from user space. It calls <tt>do_execve</tt> function.
</li><li><tt>do_execve</tt> function (in <tt>fs/exec.c</tt>) opens the executable binary file and does some preparation.
It calls <tt>search_binary_handler</tt> function.
</li><li><a href="https://web.archive.org/web/20201202024834/http://lxr.linux.no/linux/fs/exec.c#L1240"><tt>search_binary_handler</tt></a> function (in <tt>fs/exec.c</tt>) finds out the type of executable binary
and calls the corresponding handler, which in our case, is <tt>load_elf_binary</tt> function.
</li><li><a href="https://web.archive.org/web/20201202024834/http://lxr.linux.no/linux/fs/binfmt_elf.c#L564"><tt>load_elf_binary</tt></a> (in <tt>fs/binfmt_elf.c</tt>) loads the user's executable binary file into memory.
It allocates memory segments and zeros out the BSS section by calling the <tt>padzero</tt> function.
<p><tt>load_elf_binary</tt> also examines
whether the user's executable binary contains an <tt>INTERP</tt> segment or not.
</p></li><li>If the executable binary is dynamically linked, then the compiler will usually creates an
<tt>INTERP</tt> segment (which is usually the same as <tt>.interp</tt> section in
ELF's "linking view"), which contains the full pathname of an "interpreter", usually
is the Glibc runtime linker <a href="https://web.archive.org/web/20201202024834/http://linux.die.net/man/8/ld-linux">ld.so</a>.
<p>To see this, use command <tt>readelf -p .interp a.out</tt>
</p><p>According to <a href="https://web.archive.org/web/20201202024834/http://www.x86-64.org/documentation/abi.pdf">AMD64 System V Application Binary Interface</a>,
the only valid interpreter for programs conforming to AMD64 ABI is <tt>/lib/ld64.so.1</tt>
and on Linux, GCC usually uses <tt>/lib64/ld-linux-x86-64.so.2</tt>
or <tt>/lib/ld-linux-x86-64.so.2</tt> instead:
</p><pre>$ gcc -dumpspecs
....
*link:
...
%{!m32:%{!dynamic-linker:-dynamic-linker %{muclibc:%{mglibc:%e-mglibc and -muclibc used
together}/lib/ld64-uClibc.so.0;:<font color="LightGreen">/lib/ld-linux-x86-64.so.2</font>}}}}
...
</pre>
<p>To change the runtime linker, compile the program using something like </p><pre>gcc foo.c -Wl,-I/my/own/ld.so</pre>
<p>The <a href="https://web.archive.org/web/20201202024834/http://www.sco.com/developers/gabi/latest/ch5.dynamic.html">System V Application Binary Interface</a>
specifies, the operating system, instead of running the user's executable binary, should run this
"interpreter". This interpreter should complete the binding of user's executable binary
to its dependencies.
</p></li><li>Thus, if the ELF executable binary file contains an <tt>INTERP</tt> segment, <tt>load_elf_binary</tt> will
call <a href="https://web.archive.org/web/20201202024834/http://lxr.linux.no/linux/fs/binfmt_elf.c#L383"><tt>load_elf_interp</tt></a> function to load the image of this interpreter as well.
</li><li>Finally, <tt>load_elf_binary</tt> calls <tt>start_thread</tt> (in <tt>arch/x86/kernel/process_64.c</tt>)
and passes control to either the interpreter or the user program.
</li></ol>
<h2>What about <tt>ld.so</tt> ?</h2>
<tt>ld.so</tt> is the runtime linker/loader (the compile-time linker <tt>ld</tt> is formally called "link editor")
for dynamic executables. It provides the <a href="https://web.archive.org/web/20201202024834/http://download.oracle.com/docs/cd/E19963-01/html/819-0690/chapter3-1.html">following services</a>:
<ul>
<li>Analyzes the user's executable binary's <tt>DYNAMIC</tt> segment and determines what
dependencies are required. (See below)
</li><li>Locates and loads these dependencies, analyzes their <tt>DYNAMIC</tt> segments
to determine if more dependencies are required.
</li><li>Performs any necessary relocations to bind these objects.
</li><li>Calls any initialization functions (see below) provided by these dependencies.
</li><li>Passes control to user's executable binary.
</li></ul>
<h2>Compile your own <tt>ld.so</tt> </h2>
The internal working of <tt>ld.so</tt> is complex, so you might want to compile and experiment your
own <tt>ld.so</tt>.
The source code of <tt>ld.so</tt> can be found in <font color="lightgreen">Glibc</font>. The main files are
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/rtld.c"><tt>elf/rtld.c</tt></a>,
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-reloc.c"><tt>elf/dl-reloc.c</tt></a>, and
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/dl-machine.h"><tt>sysdeps/x86_64/dl-machine.h</tt></a>.
<p>
<a href="https://web.archive.org/web/20201202024834/http://www.linuxfromscratch.org/lfs/view/development/chapter05/glibc.html">This link</a>
provides general tips for building Glibc. Glibc's own
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=INSTALL">INSTALL</a> and
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=FAQ">FAQ</a> documents
are useful too.
</p><p>
To compile Glibc (<font color="lightgreen"><tt>ld.so</tt> cannot be compiled independently</font>) download and unpack Glibc source tarball.
</p><ul>
<li>Make sure the version of Glibc you downloaded is the same as the system's current one.
</li><li>Make sure the environmental variable <tt>LD_RUN_PATH</tt> is not set.
</li><li>Read the <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=INSTALL">INSTALL</a> and make sure all necessary tool chains (Make, Binutils, etc)
are up-to-date.
</li><li>Make sure the file system you are doing the compilation is <font color="lightgreen">case sensitive</font>, or
you will see <a href="https://web.archive.org/web/20201202024834/http://crossgcc.rts-software.org/doku.php?id=i386linuxgccformac">weird errors</a> like
<pre>/scratch/elf/librtld.os: In function `process_envvars':
/tmp/glibc-2.x.y/elf/rtld.c:2718: undefined reference to `__open'
...
</pre>
</li><li><tt>ld.so</tt> should be compiled with the <font color="lightgreen">optimization flag on</font>
(<tt>-O2</tt> is the default). Failing to do so will end up with weird errors (see Question 1.23 in
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=FAQ">FAQ</a>)
</li><li>Suppose Glibc is unpacked at <pre>/tmp/glibc-2.x.y/</pre>
Then edit <tt>/tmp/glibc-2.x.y/Makefile.in</tt>: Un-comment the line <pre># PARALLELMFLAGS = -j 4</pre> and
change 4 to an appropriate number.<p>
</p></li><li>Since we are only interested in <tt>ld.so</tt> and not the whole Glibc,
we only want to build the essential source files needed by <tt>ld.so</tt>.
To do so, edit <tt>/tmp/glibc-2.x.y/Makeconfig</tt>: Find the line started with
<pre>all-subdirs = csu assert ctype locale intl catgets math setjmp signal \
...
</pre>
and change it to
<pre>all-subdirs = csu elf gmon io misc posix setjmp signal stdlib string time
</pre>
</li><li>Find a scratch directory, say <tt>/scratch</tt>. Then
<pre>$ cd /scratch
$ /tmp/glibc-2.x.y/configure --prefix=/scratch --disable-profile
$ gmake
</pre>
</li><li>Since we are not building the entire Glibc, when the <tt>gmake</tt>
stops (probably with some errors), check if <tt>/scratch/elf/ld.so</tt> exists
or not.
</li><li><tt>ld.so</tt> is a static binary, which means it has its own
implementation of standard C routines (e.g. <tt>memcpy</tt>, <tt>strcmp</tt>, etc)
It has its own <tt>printf</tt>-like routine called <tt>_dl_debug_printf</tt>.
<p>
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-misc.c"><tt>_dl_debug_printf</tt></a>
is not the full-blown <tt>printf</tt> and has very limited capabilities.
For example, to print the address, one would need to use
</p><pre>_dl_debug_printf("0x%0*lx\n", (int)sizeof (void*)*2, &foo);
</pre>
</li></ul>
<h2>How does <tt>ld.so</tt> work ?</h2>
<tt>ld.so</tt>, by its nature, cannot be a dynamic executable itself. The
entry point of <tt>ld.so</tt> is <tt>_start</tt> defined in
the macro <tt>RTLD_START</tt> (in <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/dl-machine.h"><tt>sysdeps/x86_64/dl-machine.h</tt></a>).
<tt>_start</tt> is placed at the beginning of <tt>.text</tt> section, and
the default <tt>ld</tt> script specifies
"Entry point address" (in ELF header, use <tt>readelf -h ld.so|grep Entry</tt> command to see)
to be the address of <tt>_start</tt> (use <tt>ld -verbose | grep ENTRY</tt> command to see). One
can set the entry point to a different address at compile time
by <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/binutils/docs/ld/Entry-Point.html"><tt>-e</tt> option</a>)
so <tt>ld.so</tt> is executed from here. The very first thing it does is to call <tt>_dl_start</tt> of
<tt>elf/rtld.c</tt>. To see this, run gdb on some ELF executable binary, and do
<pre>(gdb) break _dl_start
Function "_dl_start" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_dl_start) pending.
(gdb) run
Starting program: a.out
Breakpoint 1, 0x0000003433e00fa0 in _dl_start () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0 0x0000003433e00fa0 in <font color="lightgreen">_dl_start</font> () from /lib64/ld-linux-x86-64.so.2
#1 0x0000003433e00a78 in <font color="lightgreen">_start</font> () from /lib64/ld-linux-x86-64.so.2
#2 0x0000000000000001 in ?? ()
#3 0x00007fffffffe4f2 in ?? ()
#4 0x0000000000000000 in ?? ()
...
(gdb) x/10i $pc
0x3433e00a70 <_start>: mov %rsp,%rdi
0x3433e00a73 <_start+3>: callq 0x3433e00fa0 <<font color="lightgreen">_dl_start</font>>
0x3433e00a78 <_dl_start_user>: mov %rax,%r12
0x3433e00a7b <_dl_start_user+3>: mov 0x21b30b(%rip),%eax # 0x343401bd8c <_dl_skip_args>
...
</pre>
At this breakpoint, we can use <tt>pmap</tt> to see the memory map of a.out, which would
look like this:
<pre>0000000000400000 8K r-x-- a.out
0000000000601000 4K rw--- a.out
0000003433e00000 112K r-x-- /lib64/ld-2.5.so
000000343401b000 8K rw--- /lib64/ld-2.5.so
00007ffffffea000 84K rw--- [ stack ]
ffffffffff600000 8192K ----- [ anon ]
total 8408K
</pre>
The memory segment of <tt>/lib64/ld-2.5.so</tt> indeed starts at 3433e00000 (page aligned) and
this can be verified by running <tt>readelf -t /lib64/ld-2.5.so</tt>.
<p>
If we put another breakpoint at <tt>main</tt> and continue, then when it stops, the memory
map would change to this:
</p><pre>0000000000400000 8K r-x-- a.out
0000000000601000 4K rw--- a.out
0000003433e00000 112K r-x-- /lib64/ld-2.5.so
000000343401b000 4K r---- /lib64/ld-2.5.so
000000343401c000 4K rw--- /lib64/ld-2.5.so
<font color="lightgreen">0000003434200000 1336K r-x-- /lib64/libc-2.5.so <-- The first "LOAD" segment, which contains .text and .rodata sections
000000343434e000 2044K ----- /lib64/libc-2.5.so <-- "Hole"
000000343454d000 16K r---- /lib64/libc-2.5.so <-- Relocation (GNU_RELRO) info -+---- The second "LOAD" segment
0000003434551000 4K rw--- /lib64/libc-2.5.so <-- .got.plt .data sections -+
0000003434552000 20K rw--- [ anon ] <-- The remaining zero-filled sections (e.g. .bss)
0000003434e00000 88K r-x-- /lib64/libpthread-2.5.so <-- The first "LOAD" segment, which contains .text and .rodata sections
0000003434e16000 2044K ----- /lib64/libpthread-2.5.so <-- "Hole"
0000003435015000 4K r---- /lib64/libpthread-2.5.so <-- Relocation (GNU_RELRO) info -+---- The second "LOAD" segment
0000003435016000 4K rw--- /lib64/libpthread-2.5.so <-- .got.plt .data sections -+
0000003435017000 16K rw--- [ anon ] <-- The remaining zero-filled sections (e.g. .bss)
00002aaaaaaab000 4K rw--- [ anon ]
00002aaaaaac6000 12K rw--- [ anon ]</font>
00007ffffffea000 84K rw--- [ stack ]
ffffffffff600000 8192K ----- [ anon ]
total 14000K
</pre>
Indeed, <tt>ld.so</tt> has brought in all the required dynamic libraries.<p>Note that there
are two memory regions of 2044KB with <font color="lightgreen">null permissions</font>.
As mentioned earlier, the ELF's 'execution view' is concerned with how to load an executable
binary into memory. When <tt>ld.so</tt> brings in the dynamic libraries, it looks at the segments labelled
as <tt>LOAD</tt> (look at "Program Headers" and "Section to Segment mapping"
from <tt>readelf -a xxx.so</tt> command.) Usually there are two <tt>LOAD</tt> segments, and
there is a "hole" between the two segments (look at the VirtAddr and MemSiz of these
two segments), so <tt>ld.so</tt> will
make this hole inaccessible deliberately: Look for the <tt>PROT_NONE</tt> symbol in
<tt>_dl_map_object_from_fd</tt> in <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-load.c"><tt>elf/dl-load.c</tt></a>
</p><p>
Also note that each of
<tt>libc-2.5.so</tt> and <tt>libpthread-2.5.so</tt> has a read-only memory region
(at 0x343454d000 and 0x3435015000, respectively). This is a for
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-reloc.c"><tt>elf/dl-reloc.c</tt></a>.
The <tt>GNU_RELRO</tt> segment is contained in the the second <tt>LOAD</tt> segment, which
contains the following sections (look at "Program Headers" and "Section to Segment mapping"
from <tt>readelf -l xxx.so</tt> command):
<tt>.tdata</tt>, <tt>.fini_array</tt>, <tt>.ctors</tt>, <tt>.dtors</tt>, <tt>__libc_subfreeres</tt>,
<tt>__libc_atexit</tt>, <tt>__libc_thread_subfreeres</tt>, <tt>.data.rel.ro</tt>, <tt>.dynamic</tt>,
<tt>.got</tt>, <tt>.got.plt</tt>, <tt>.data</tt>, and <tt>.bss</tt>. Except for
<tt>.got.plt</tt>, <tt>.data</tt>, and <tt>.bss</tt>, all sections in the the second <tt>LOAD</tt> segment
are also in the <tt>GNU_RELRO</tt> segment, and they are thus made read-only.
</p><p>
The two <tt>[anon]</tt> memory segments at 0x3434552000 and 0x3435017000 are for sections which do not take space in the ELF
binary files. For example, <tt>readelf -t xxx.so</tt> will show that <tt>.bss</tt> section
has <tt>NOBITS</tt> flag, which means that section takes no disk space. When segments
containing <tt>NOBITS</tt> sections are mapped into memory, <tt>ld.so</tt> allocates
extra memory pages to accomodate these <tt>NOBITS</tt> sections. A <tt>LOAD</tt>
segment is usually structured as a series of <b>contiguous</b> sections, and if
a segment contains <tt>NOBITS</tt> sections, these <tt>NOBITS</tt> sections will
be grouped together and placed at the tail of the segment.
</p><p>
So what does <tt>_dl_start</tt> do ?
</p><ul>
<li>Allocate the initial TLS block and initialize the Thread Pointer if needed (these are for <tt>ld.so</tt>'s own, not for the user program)
</li><li>Call <tt>_dl_sysdep_start</tt>, which will call <tt>dl_main</tt>
</li><li><tt>dl_main</tt> does the majority of the hard work, for example:<p>
It calls <tt>process_envvars</tt> to handle these <tt>LD_</tt> prefix environmental
variables such as <tt>LD_PRELOAD</tt>, <tt>LD_LIBRARY_PATH</tt>.</p><p>
It examines the <tt>NEEDED</tt> field(s) in the user executable binary's <tt>DYNAMIC</tt> segment
section (see below) to determine the dependencies.</p><p>
It calls <tt>_dl_init_paths</tt> (in <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-load.c"><tt>elf/dl-load.c</tt></a>)
to initialize the dynamic libraries search paths.
According to <a href="https://web.archive.org/web/20201202024834/http://manpages.courier-mta.org/htmlman8/ld.so.8.html"><tt>ld.so</tt> man page</a>
and <a href="https://web.archive.org/web/20201202024834/http://blog.lxgcc.net/?tag=dt_runpath">this page</a>,
the dynamic libraries are searched in the following order:
</p><p>
</p><ol>
<li>The <tt>RPATH</tt> in the <tt>DYNAMIC</tt> segment if there is no
<tt>RUNPATH</tt> in the <tt>DYNAMIC</tt> segment.
<p><tt>RPATH</tt> can be specified when
the code is compiled with <tt>gcc -Wl,-rpath=...</tt>
</p><p><font color="red">Use of <tt>RPATH</tt> is deprecated</font>
because it has an obvious drawback: There is no way to override
it except using <tt>LD_PRELOAD</tt> environmental variable
or removing it from the <tt>DYNAMIC</tt> segment.
</p><p>Both <tt>RPATH</tt> and <tt>RUNPATH</tt> can
contain <font color="LightGreen"><tt>$ORIGIN</tt></font>
(or equivalently <font color="LightGreen"><tt>${ORIGIN}</tt></font>), which will be
expanded to the value of environmental variable <tt>LD_ORIGIN_PATH</tt>
or the full path of the loaded object
(unless the programs use <tt>setuid</tt> or <tt>setgid</tt>)
</p><p>
</p></li><li>The <tt>LD_LIBRARY_PATH</tt> environmental variable (unless
the programs use <tt>setuid</tt> or <tt>setgid</tt>)
</li><li>The <tt>RUNPATH</tt> in the <tt>DYNAMIC</tt> segment.<br><tt>RUNPATH</tt> can be specified when
the code is compiled with <tt>gcc -Wl,-rpath=...<font color="LightGreen">,--enable-new-dtags</font></tt>
<br>
One can use <a href="https://web.archive.org/web/20201202024834/http://linux.die.net/man/1/chrpath">chrpath</a>
tool to manipulate <tt>RPATH</tt> and <tt>RUNPATH</tt> settings.
</li><li><a href="https://web.archive.org/web/20201202024834/http://manpages.courier-mta.org/htmlman8/ldconfig.8.html"><tt>/etc/ld.so.cache</tt></a>
</li><li><tt>/lib</tt>
</li><li><tt>/usr/lib</tt>
</li></ol>
<p>
It calls <tt>_dl_map_object_from_fd</tt> (in <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-load.c"><tt>elf/dl-load.c</tt></a>)
to load the dynamic libraries, sets up the right read/write/execute permissions for the memory segments,
(within <tt>_dl_map_object_from_fd</tt>, look at calls to <tt>mmap</tt>, <tt>mprotect</tt> and symbols such as
<tt>PROT_READ</tt>, <tt>PROT_WRITE</tt>, <tt>PROT_EXEC</tt>, <tt>PROT_NONE</tt>),
<b>zeroes out BSS sections of dynamic libraries</b> (inside <tt>_dl_map_object_from_fd</tt> function, look at calls to <tt>memset</tt>),
updates the link map, and performs relocations.</p><p>
It calls <tt>_dl_relocate_object</tt> (in <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-reloc.c"><tt>elf/dl-reloc.c</tt></a>) to perform <b>runtime relocations</b> (see details below).
</p><p>
</p></li><li>When <tt>_dl_start</tt> returns, it continues to execute
code in <tt>_dl_start_user</tt> (see <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/dl-machine.h"><tt>sysdeps/x86_64/dl-machine.h</tt></a>)
</li><li><tt>_dl_start_user</tt> will call <tt>_dl_init_internal</tt>, which will call <tt>call_init</tt>
to invoke initialization function of each dynamic library loaded.
<p>Note that <tt>_dl_init_internal</tt> is defined in <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-init.c"><tt>elf/dl-init.c</tt></a> as:
</p><pre>void
internal_function
_dl_init (struct link_map *main_map, int argc, char **argv, char **env)
</pre>
<tt>call_init</tt> is also in <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-init.c"><tt>elf/dl-init.c</tt></a><p>
</p></li><li>The initialization function of a dynamic library, say <tt>libfoo.so</tt>, is located at the
address marked with type "<tt>INIT</tt>" in the output of <tt>readelf -d libfoo.so</tt>
<font color="lightgreen">For Glibc, its initialization function is named <tt>_init</tt></font> (not to be confused with the <tt>_init</tt>
inside the user's executable binary) and its source code is in
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/unix/sysv/linux/x86_64/init-first.c"><tt>sysdeps/unix/sysv/linux/x86_64/init-first.c</tt></a>.
<p><tt>_init</tt> will do the following things:
</p><ul>
<li>Save <tt>argc</tt>, <tt>argv</tt>, <tt>envp</tt> to hidden variables
<tt>__libc_argc</tt>, <tt>__libc_argv</tt>, <tt>__environ</tt>
</li><li>Call <tt>VDSO_SETUP</tt> to set up Virtaul Dynamic Shared Objects (see <a href="https://web.archive.org/web/20201202024834/http://www.acsu.buffalo.edu/%7Echarngda/x86assembly.html">here</a>)
<tt>VDSO_SETUP</tt> is a platform-dependent macro. For x86_64, this macro is defined as
<tt>_libc_vdso_platform_setup</tt> in <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/unix/sysv/linux/x86_64/init-first.c"><tt>sysdeps/unix/sysv/linux/x86_64/init-first.c</tt></a>
</li><li>Call <tt>__init_misc</tt> (in
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=misc/init-misc.c"><tt>misc/init-misc.c</tt></a>) which saves <tt>argv[0]</tt>
to two global variables: <tt>program_invocation_name</tt> and <tt>program_invocation_short_name</tt>
</li><li>Call <tt>__libc_global_ctors</tt> (in <a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/soinit.c"><tt>elf/soinit.c</tt></a>) to invoke each function listed in
the <tt>.ctors</tt> section (see below).<p>
For x86_64, <tt>.ctors</tt> section contains only one function: <tt>init_cacheinfo</tt></p><p>
</p></li></ul>
</li><li>At the end of <tt>_dl_start_user</tt>, the control transfers to user program's entry point address (use <tt>readelf -h a.out|grep Entry</tt> to see)
which is usually the initial address of <tt>.text</tt> section and contains
the entry of a function named <tt>_start</tt>, and in the control transfer, the finalizer function
<tt>_dl_fini</tt> is passed as an argument,
and the stack frames are completely clobbered, as if the user program
is run without any <tt>ld.so</tt> intervention. The latter is done by manipulating the stack (see the
<a href="https://web.archive.org/web/20201202024834/http://articles.manugarg.com/aboutelfauxiliaryvectors.html">on-stack auxiliary vector</a> adjustment
code and <tt>HAVE_AUX_VECTOR</tt> in <tt>dl_main</tt>)
</li></ul>
<p>
</p><center><h1>Here is the <a href="https://web.archive.org/web/20201202024834/http://www.acsu.buffalo.edu/%7Echarngda/code/gdb_callgraph/examples/callgraphLDSO.gif">call graph</a>,
which is worth a thousand words</h1> and see <a href="https://web.archive.org/web/20201202024834/http://www.acsu.buffalo.edu/%7Echarngda/callgraph.html">here</a>
on how it is generated.</center>
<p>
<font color="lightgreen">To see <tt>ld.so</tt> in action, set the environmental
variable <tt>LD_DEBUG</tt> to <tt>all</tt></font> and then run a user program.
</p><p>The above debugging information does not show <tt>mmap</tt> and <tt>mprotect</tt> calls.
However, we can use <tt>strace</tt>. If we run the user program again with
</p><pre>strace -e trace=mmap,mprotect,munmap,open a.out</pre> we should see something like the
following:
<pre>mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ae62c0d1000
.... (a lot of failed attempts to open 'libpthread.so.0' using LD_LIBRARY_PATH)
<font color="LightBlue">open("/etc/ld.so.cache", O_RDONLY) = 3
mmap(NULL, 104801, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2ae62c0d2000</font>
<font color="LightCoral">open("/lib64/libpthread.so.0", O_RDONLY) = 3</font>
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ae62c0ec000
<font color="LightCoral">mmap(0x3434e00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3434e00000 <-- Bring in the first "LOAD" segment
mprotect(0x3434e16000, 2093056, PROT_NONE) = 0 <-- Make the "hole" inaccessible
mmap(0x3435015000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x3435015000 <-- Bring in the second "LOAD" segment
mmap(0x3435017000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3435017000</font>
(note: 0x3435017000 is the [anon] part which follows immediately after libpthread-2.5.so)
...
.... (a lot of failed attempts to open 'libc.so.6' using LD_LIBRARY_PATH)
<font color="Orange">open("/lib64/libc.so.6", O_RDONLY) = 3
mmap(0x3434200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3434200000 <-- Bring in the first "LOAD" segment
mprotect(0x343434e000, 2093056, PROT_NONE) = 0 <-- Make the "hole" inaccessible
mmap(0x343454d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14d000) = 0x343454d000 <-- Bring in the second "LOAD" segment
mmap(0x3434552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3434552000</font>
(note: 0x3434552000 is the [anon] part which follows immediately after libc-2.5.so)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ae62c0ed000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ae62c0ee000
<font color="Orange">mprotect(0x343454d000, 16384, PROT_READ) = 0</font> <-- Make the GNU_RELRO segment read-only
<font color="LightCoral">mprotect(0x3435015000, 4096, PROT_READ) = 0</font> <-- Make the GNU_RELRO segment read-only
mprotect(0x343401b000, 4096, PROT_READ) = 0
<font color="LightBlue">munmap(0x2ae62c0d2000, 104801)= 0</font>
mmap(NULL, 10489856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0) = 0x40dc7000
mprotect(0x40dc7000, 4096, PROT_NONE) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaaab000
</pre>
<h2><tt>.plt</tt> section</h2>
This section contains trampolines for functions defined in dynamic libraries.
A sample disassembly (run the command <tt>objdump -M intel -dj .plt a.out</tt>) will show the following:
<pre>4003c0 <<font color="lightgreen">printf@plt-0x10</font>>:
4003c0: push QWORD PTR [RIP+0x2004d2] # 600898 <_GLOBAL_OFFSET_TABLE_+0x8>
4003c6: jmp QWORD PTR [RIP+0x2004d4] # 6008a0 <_GLOBAL_OFFSET_TABLE_+0x10>
4003cc: nop DWORD PTR [RAX+0x0]
4003d0 <printf@plt>:
4003d0: jmp QWORD PTR [RIP+0x2004d2] # <font color="lightgreen">6008a8</font> <_GLOBAL_OFFSET_TABLE_+0x18>
4003d6: push 0
4003db: jmp 4003c0 <<font color="lightgreen">printf@plt-0x10</font>>
4003e0 <__libc_start_main@plt>:
4003e0: jmp QWORD PTR [RIP+0x2004ca] # 6008b0 <_GLOBAL_OFFSET_TABLE_+0x20>
4003e6: push 1
4003eb: jmp 4003c0 <<font color="lightgreen">printf@plt-0x10</font>>
</pre>
The <tt>_GLOBAL_OFFSET_TABLE_</tt> (labeled as <tt>R_X86_64_JUMP_SLOT</tt> and starts at address 0x600890) is located in
<tt>.got.plt</tt> section (to see this, run the command <tt>objdump -h a.out |grep -A 1 600890</tt>
or the command <tt>readelf -r a.out</tt>)
The data in <tt>.got.plt</tt> section look like the following <font color="lightgreen">during runtime</font>
(use gdb to see them)
<pre>(gdb) b *0x4003d0
(gdb) run
(gdb) x/6a 0x600890
0x600890: 0x6006e8 <_DYNAMIC> 0x32696159a8
0x6008a0: 0x326950aa20 <_dl_runtime_resolve> <font color="lightgreen">0x4003d6</font> <printf@plt+6>
0x6008b0: 0x326971c3f0 <__libc_start_main> 0x0
</pre>
When <tt>printf</tt> is called the first time in the user program, the
jump at 4003d0 will jump to <font color="lightgreen">4003d6</font>, which is just the next instruction (<tt>push 0</tt>)
The it jumps to 4003c0, which does not have a function name (so it is
shown as <tt><printf@plt-0x10></tt>). At 4003c6, it will jumps
to <tt>_dl_runtime_resolve</tt>. This function (in Glibc's source file
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/dl-trampoline.S"><tt>sysdeps/x86_64/dl-trampoline.S</tt></a>)
is a trampoline to <tt>_dl_fixup</tt> (in Glibc's source file
<a href="https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/dl-runtime.c"><tt>elf/dl-runtime.c</tt></a>).
<tt>_dl_fixup</tt> again, is part of Glibc runtime linker <tt>ld.so</tt>. In particular, <font color="lightgreen">it will change
the address stored at 6008a8 to the actual
address of <tt>printf</tt> in <tt>libc.so.6</tt></font>. To see this, set up a
hardware watchpoint
<pre>(gdb) watch *0x6008a8
(gdb) cont
Continuing.
Hardware watchpoint 2: *0x6008a8
Old value = 4195286
New value = 1769244016