Contained in bytes 0x40 to 0x7F.
The first section is always magic: www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html says:
If the number of sections is greater than or equal to SHN_LORESERVE (0xff00), e_shnum has the value SHN_UNDEF (0) and the actual number of section header table entries is contained in the sh_size field of the section header at index 0 (otherwise, the sh_size member of the initial entry contains 0).
There are also other magic sections detailed in
Figure 4-7: Special Section Indexes.In index 0,
SHT_NULL is mandatory. Are there any other uses for it: stackoverflow.com/questions/26812142/what-is-the-use-of-the-sht-null-section-in-elf ?Sections with
sh_type == SHT_STRTAB are called string tables.They hold a null separated array of strings.
Such sections are used by other sections when string names are to be used. The using section says:
- which string table they are using
- what is the index on the target string table where the string starts
So for example, we could have a string table containing:
Data: \0 a b c \0 d e f \0
Index: 0 1 2 3 4 5 6 7 8And if another section wants to use the string
d e f, they have to point to index 5 of this section (letter d).Notable string table sections:
.shstrtab.strtab
Section type:
sh_type == SHT_STRTAB.Common name: "section header string table".
This section gets pointed to by the
e_shstrnd field of the ELF header itself.String indexes of this section are are pointed to by the
sh_name field of section headers, which denote strings.This section does not have outputs:
SHF_ALLOC marked, so it will not appear on the executing program.readelf -x .shstrtab hello_world.oHex dump of section '.shstrtab':
0x00000000 002e6461 7461002e 74657874 002e7368 ..data..text..sh
0x00000010 73747274 6162002e 73796d74 6162002e strtab..symtab..
0x00000020 73747274 6162002e 72656c61 2e746578 strtab..rela.tex
0x00000030 7400 t.Section type:
sh_type == SHT_SYMTAB.A good high level tool to disassemble that section is:which gives:
nm hello_world.o0000000000000000 T _start
0000000000000000 d hello_world
000000000000000d a hello_world_lenThis is however a high level view that omits some types of symbols and in which the symbol types . A more detailed disassembly can be obtained with:which gives:
readelf -s hello_world.oSymbol table '.symtab' contains 7 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS hello_world.asm
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 SECTION LOCAL DEFAULT 2
4: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 hello_world
5: 000000000000000d 0 NOTYPE LOCAL DEFAULT ABS hello_world_len
6: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 2 _startThe binary format of the table is documented at www.sco.com/developers/gabi/2003-12-17/ch4.symtab.html
The data is:which gives:
readelf -x .symtab hello_world.oHex dump of section '.symtab':
0x00000000 00000000 00000000 00000000 00000000 ................
0x00000010 00000000 00000000 01000000 0400f1ff ................
0x00000020 00000000 00000000 00000000 00000000 ................
0x00000030 00000000 03000100 00000000 00000000 ................
0x00000040 00000000 00000000 00000000 03000200 ................
0x00000050 00000000 00000000 00000000 00000000 ................
0x00000060 11000000 00000100 00000000 00000000 ................
0x00000070 00000000 00000000 1d000000 0000f1ff ................
0x00000080 0d000000 00000000 00000000 00000000 ................
0x00000090 2d000000 10000200 00000000 00000000 -...............
0x000000a0 00000000 00000000 ........The entries are of type:
typedef struct {
Elf64_Word st_name;
unsigned char st_info;
unsigned char st_other;
Elf64_Half st_shndx;
Elf64_Addr st_value;
Elf64_Xword st_size;
} Elf64_Sym;- 10 8:
st_name=01000000= character 1 in the.strtab, which until the following\0makeshello_world.asmThis piece of information file may be used by the linker to decide on which segment sections go: e.g. inldlinker script we write:segment_name : { file(section) }segment_name : { *(section) } - 10 13:
st_shndx= Symbol Table Section header Index =f1ff=SHN_ABS. Required forSTT_FILE. - 20 0:
st_value= 8x00: required for value forSTT_FILE - 20 8:
st_size= 8x00: no allocated size
Now from the
readelf, we interpret the others quickly.There are two such entries, one pointing to
.data and the other to .text (section indexes 1 and 2).Num: Value Size Type Bind Vis Ndx Name
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 SECTION LOCAL DEFAULT 2TODO what is their purpose?
Then come the most important symbols:
Num: Value Size Type Bind Vis Ndx Name
4: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 hello_world
5: 000000000000000d 0 NOTYPE LOCAL DEFAULT ABS hello_world_len
6: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 2 _starthello_world_len points to the special st_shndx == SHN_ABS == 0xF1FF.0xF1FF is chosen so as to not conflict with other sections.st_value == 0xD == 13 which is the value we have stored there on the assembly: the length of the string Hello World!.This is small optimization that our assembler does for us and which has ELF support.
Holds strings for the symbol table.
This section has
sh_type == SHT_STRTAB.It is pointed to by outputs:
sh_link == 5 of the .symtab section.readelf -x .strtab hello_world.oHex dump of section '.strtab':
0x00000000 0068656c 6c6f5f77 6f726c64 2e61736d .hello_world.asm
0x00000010 0068656c 6c6f5f77 6f726c64 0068656c .hello_world.hel
0x00000020 6c6f5f77 6f726c64 5f6c656e 005f7374 lo_world_len._st
0x00000030 61727400 art.This implies that it is an ELF level limitation that global variables cannot contain NUL characters.
Section type:
sh_type == SHT_RELA.Common name: "relocation section".
.rela.text holds relocation data which says how the address should be modified when the final executable is linked. This points to bytes of the text area that must be modified when linking happens to point to the correct memory locations.Basically, it translates the object text containing the placeholder 0x0 address:to the actual executable code containing the final 0x6000d8:
a: 48 be 00 00 00 00 00 movabs $0x0,%rsi
11: 00 00 004000ba: 48 be d8 00 60 00 00 movabs $0x6000d8,%rsi
4000c1: 00 00 00It was pointed to by
sh_info = 6 of the .symtab section.readelf -r hello_world.o outputs:Relocation section '.rela.text' at offset 0x3b0 contains 1 entries:
Offset Info Type Sym. Value Sym. Name + Addend
00000000000c 000200000001 R_X86_64_64 0000000000000000 .data + 0The section does not exist in the executable.
The actual bytes are:
00000370 0c 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 |................|
00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|The
struct represented is:typedef struct {
Elf64_Addr r_offset;
Elf64_Xword r_info;
Elf64_Sxword r_addend;
} Elf64_Rela;So:
- 370 0:
r_offset= 0xC: address into the.textwhose address this relocation will modify - 370 8:
r_info= 0x200000001. Contains 2 fields:ELF64_R_TYPE= 0x1: meaning depends on the exact architecture.ELF64_R_SYM= 0x2: index of the section to which the address points, so.datawhich is at index 2.
The AMD64 ABI says that type1is calledR_X86_64_64and that it represents the operationS + Awhere:This address is added to the section on which the relocation operates. - 380 0:
r_addend= 0
Contains the path to the dynamic loader, i.e.
/lib64/ld-linux-x86-64.so.2 in Ubuntu 18.10. Explained at: stackoverflow.com/questions/8040631/checking-if-a-binary-compiled-with-static/55664341#55664341file 5.36 however does use it to display file type as explained at: stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/55704865#55704865Whenever Ciro Santilli learns about molecular biology, he can't help but to feel that it feels like programming, and notably systems programming and computer hardware design.
In some sense, the comparison is obvious: DNA is clearly a programmable medium like any assembly language, but still, systems programming did give Ciro some further feelings.
- The most important analogy perhaps is observability, or more precisely the lack of it. For the computer, this is described at: The lower level you go into a computer, the harder it is to observe things.And then, when Ciro started learning a bit about biology techniques, he started to feel the exact same thing.For example when he played with E. Coli Whole Cell Model by Covert Lab, the main thing Ciro felt was: it is going to be hard to verify any of this data, because it is hard/impossible to know the concentration of each element in a cell as a function of time.More generally of course, this is exactly why making any biology discovery is so hard: we can't easily see what's going on inside the cell, and have to resort to indirect ways of doing so..This exact idea was highlighted by I should have loved biology by James Somers:
For a computer scientist, a biologist's methods can seem insane; the trouble comes from the fact that cells are too small, too numerous, too complex to analyze the way a programmer would, say in a step-by-step debugger.
And then just like in software, some of the methods biologists use to overcome the lack of visibility have direct software analogues:- add instrumentation to cells, e.g. GFP tagging comes to mind
- emulation, e.g. E. Coli Whole Cell Model by Covert Lab
- The boot process is another one. E.g. in x86 the way that you start in 16-bit mode, largely compatible into the 70's, then move to 32-bit and finally 64, does feel a lot the way a earlier stages of embryo development looks more and more like more ancient animals.
Ciro likes to think that maybe that is why a hardcore systems programmer like Bert Hubert got into molecular biology.
Some other people who mention similar things:
- I should have loved biology by James Somers highlights the computer abstraction layer analogy between the two:
Pinned article: Introduction to the OurBigBook Project
Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
Intro to OurBigBook
. Source. We have two killer features:
- topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculusArticles of different users are sorted by upvote within each article page. This feature is a bit like:
- a Wikipedia where each user can have their own version of each article
- a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
Figure 1. Screenshot of the "Derivative" topic page. View it live at: ourbigbook.com/go/topic/derivativeVideo 2. OurBigBook Web topics demo. Source. - local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
- to OurBigBook.com to get awesome multi-user features like topics and likes
- as HTML files to a static website, which you can host yourself for free on many external providers like GitHub Pages, and remain in full control
Figure 3. Visual Studio Code extension installation.
Figure 4. Visual Studio Code extension tree navigation.
Figure 5. Web editor. You can also edit articles on the Web editor without installing anything locally.Video 3. Edit locally and publish demo. Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.Video 4. OurBigBook Visual Studio Code extension editing and navigation demo. Source. 
- Infinitely deep tables of contents:
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact