慕冬亮
9 years ago
commit
584e9c9b20
@ -0,0 +1,635 @@
|
||||
Introduction
|
||||
---------------
|
||||
|
||||
During the writing of the [linux-insides](http://0xax.gitbooks.io/linux-insides/content/) book I have received many emails with questions related to the [linker](https://en.wikipedia.org/wiki/Linker_%28computing%29) script and linker-related subjects. So I've decided to write this to cover some aspects of the linker and the linking of object files.
|
||||
|
||||
If we open page the `Linker` page on wikipidia, we can see the following definition:
|
||||
|
||||
>In computer science, a linker or link editor is a computer program that takes one or more object files generated by a compiler and combines them into a single executable file, library file, or another object file.
|
||||
|
||||
If you've written at least one program on C in your life, you will have seen files with the `*.o` extension. These files are [object files](https://en.wikipedia.org/wiki/Object_file). Object files are blocks of machine code and data with placeholder addresses that reference data and functions in other object files or libraries, as well as a list of its own functions and data. The main purpose of the linker is collect/handle the code and data of each object file, turning it into the the final executable file or library. In this post we will try to go through all aspects of this process. Let's start.
|
||||
|
||||
Linking process
|
||||
---------------
|
||||
|
||||
Let's create simple project with the following structure:
|
||||
|
||||
```
|
||||
*-linkers
|
||||
*--main.c
|
||||
*--lib.c
|
||||
*--lib.h
|
||||
```
|
||||
|
||||
And write there our example factorial program. Our `main.c` source code file contains:
|
||||
|
||||
```C
|
||||
#include <stdio.h>
|
||||
|
||||
#include "lib.h"
|
||||
|
||||
int main(int argc, char **argv) {
|
||||
printf("factorial of 5 is: %d\n", factorial(5));
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
The `lib.c` file contains:
|
||||
|
||||
```C
|
||||
int factorial(int base) {
|
||||
int res = 1, i = 1;
|
||||
|
||||
if (base == 0) {
|
||||
return 1;
|
||||
}
|
||||
|
||||
while (i <= base) {
|
||||
res *= i;
|
||||
i++;
|
||||
}
|
||||
|
||||
return res;
|
||||
}
|
||||
```
|
||||
|
||||
And the `lib.h` file contains:
|
||||
|
||||
```C
|
||||
#ifndef LIB_H
|
||||
#define LIB_H
|
||||
|
||||
int factorial(int base);
|
||||
|
||||
#endif
|
||||
```
|
||||
|
||||
Now let's compile only the `main.c` source code file with:
|
||||
|
||||
```
|
||||
$ gcc -c main.c
|
||||
```
|
||||
|
||||
If we look inside the outputted object file with the `nm` util, we will see the
|
||||
following output:
|
||||
|
||||
```
|
||||
$ nm -A main.o
|
||||
main.o: U factorial
|
||||
main.o:0000000000000000 T main
|
||||
main.o: U printf
|
||||
```
|
||||
|
||||
The `nm` util allows us to see the list of symbols from the given object file. It consists of three columns: the first is the name of the given object file and the address of any resolved symbols. The second column contains a character that represents the status of the given symbol. In this case the `U` means `undefined` and the `T` denotes that the symbols are placed in the `.text` section of the object. The `nm` utility shows us here that we have three symbols in the `main.c` source code file:
|
||||
|
||||
* `factorial` - the factorial function defined in the `lib.c` source code file. It is marked as `undefined` here because we compiled only the `main.c` source code file, and it does not know anything about code from the `lib.c` file for now;
|
||||
* `main` - the main function;
|
||||
* `printf` - the function from the [glibc](https://en.wikipedia.org/wiki/GNU_C_Library) library. `main.c` does not know anything about it for now either.
|
||||
|
||||
What can we understand from the output of `nm` so far? The `main.o` object file contains the local symbol `main` at address `0000000000000000` (it will be filled with correct address after is is linked), and two unresolved symbols. We can see all of this information in the disassembly output of the `main.o` object file:
|
||||
|
||||
```
|
||||
$ objdump -S main.o
|
||||
|
||||
main.o: file format elf64-x86-64
|
||||
Disassembly of section .text:
|
||||
|
||||
0000000000000000 <main>:
|
||||
0: 55 push %rbp
|
||||
1: 48 89 e5 mov %rsp,%rbp
|
||||
4: 48 83 ec 10 sub $0x10,%rsp
|
||||
8: 89 7d fc mov %edi,-0x4(%rbp)
|
||||
b: 48 89 75 f0 mov %rsi,-0x10(%rbp)
|
||||
f: bf 05 00 00 00 mov $0x5,%edi
|
||||
14: e8 00 00 00 00 callq 19 <main+0x19>
|
||||
19: 89 c6 mov %eax,%esi
|
||||
1b: bf 00 00 00 00 mov $0x0,%edi
|
||||
20: b8 00 00 00 00 mov $0x0,%eax
|
||||
25: e8 00 00 00 00 callq 2a <main+0x2a>
|
||||
2a: b8 00 00 00 00 mov $0x0,%eax
|
||||
2f: c9 leaveq
|
||||
30: c3 retq
|
||||
```
|
||||
|
||||
Here we are interested only in the two `callq` operations. The two `callq` operations contain `linker stubs`, or the function name and offset from it to the next instruction. These stubs will be updated to the real addresses of the functions. We can see these functions' names with in the following `objdump` output:
|
||||
|
||||
```
|
||||
$ objdump -S -r main.o
|
||||
|
||||
...
|
||||
14: e8 00 00 00 00 callq 19 <main+0x19>
|
||||
15: R_X86_64_PC32 factorial-0x4
|
||||
19: 89 c6 mov %eax,%esi
|
||||
...
|
||||
25: e8 00 00 00 00 callq 2a <main+0x2a>
|
||||
26: R_X86_64_PC32 printf-0x4
|
||||
2a: b8 00 00 00 00 mov $0x0,%eax
|
||||
...
|
||||
```
|
||||
|
||||
The `-r` or `--reloc ` flags of the `objdump` util print the `relocation` entries of the file. Now let's look in more detail at the relocation process.
|
||||
|
||||
Relocation
|
||||
------------
|
||||
|
||||
Relocation is the process of connecting symbolic references with symbolic definitions. Let's look at the previous snippet from the `objdump` output:
|
||||
|
||||
```
|
||||
14: e8 00 00 00 00 callq 19 <main+0x19>
|
||||
15: R_X86_64_PC32 factorial-0x4
|
||||
19: 89 c6 mov %eax,%esi
|
||||
```
|
||||
|
||||
Note `e8 00 00 00 00` on the first line. The `e8` is the [opcode](https://en.wikipedia.org/wiki/Opcode) of the `call` instruction with a relative offset. So the `e8 00 00 00 00` contains a one-byte operation code followed by a four-byte address. Note that the `00 00 00 00` is 4-bytes, but why only 4-bytes if an address can be 8-bytes in the `x86_64`? Actually we compiled the `main.c` source code file with the `-mcmodel=small`. From the `gcc` man:
|
||||
|
||||
```
|
||||
-mcmodel=small
|
||||
Generate code for the small code model: the program and its symbols must be linked in the lower 2 GB of the address space. Pointers are 64 bits. Programs can be statically or dynamically linked. This is the default code model.
|
||||
```
|
||||
|
||||
Of course we didn't pass this option to the `gcc` when we compiled the `main.c`, but it is default. We know that our program will be linked in the lower 2 GB of the address space from the quote from the `gcc` manual. With this code model, 4-bytes is enough to represent the address. So we have opcode of the `call` instruction and unknown address. When we compile `main.c` with all dependencies to the executable file and will look on the call of the factorial we will see:
|
||||
|
||||
```
|
||||
$ gcc main.c lib.c -o factorial | objdump -S factorial | grep factorial
|
||||
|
||||
factorial: file format elf64-x86-64
|
||||
...
|
||||
...
|
||||
0000000000400506 <main>:
|
||||
40051a: e8 18 00 00 00 callq 400537 <factorial>
|
||||
...
|
||||
...
|
||||
0000000000400537 <factorial>:
|
||||
400550: 75 07 jne 400559 <factorial+0x22>
|
||||
400557: eb 1b jmp 400574 <factorial+0x3d>
|
||||
400559: eb 0e jmp 400569 <factorial+0x32>
|
||||
40056f: 7e ea jle 40055b <factorial+0x24>
|
||||
...
|
||||
...
|
||||
```
|
||||
|
||||
As we can see in the previous output, the address of the `main` function is `0x0000000000400506`. Why it does not starts from the `0x0`? You may already know that standard C programs are linked with the `glibc` C standard library unless `-nostdlib` is passed to `gcc`. The compiled code for a program includes constructors functions to initialize data in the program when the program is started. These functions need to be called before the program is started or in another words before the `main` function is called. To make the initialization and termination functions work, the compiler must output something in the assembler code to cause those functions to be called at the appropriate time. Execution of this program will starts from the code that is placed in the special section which is called `.init`. We can see it in the beginning of the objdump output:
|
||||
|
||||
```
|
||||
objdump -S factorial | less
|
||||
|
||||
factorial: file format elf64-x86-64
|
||||
|
||||
Disassembly of section .init:
|
||||
|
||||
00000000004003a8 <_init>:
|
||||
4003a8: 48 83 ec 08 sub $0x8,%rsp
|
||||
4003ac: 48 8b 05 a5 05 20 00 mov 0x2005a5(%rip),%rax # 600958 <_DYNAMIC+0x1d0>
|
||||
```
|
||||
|
||||
Note that it starts at the `0x00000000004003a8` address relative to the `glibc` code. We can check it also in the resulted [ELF](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format):
|
||||
|
||||
```
|
||||
$ readelf -d factorial | grep \(INIT\)
|
||||
0x000000000000000c (INIT) 0x4003a8
|
||||
```
|
||||
|
||||
So, the address of the `main` function is the `0000000000400506` and it is offset from the `.init` section. As we can see from the output, the address of the `factorial` function is `0x0000000000400537` and binary code for the call of the `factorial` function now is `e8 18 00 00 00`. We already know that `e8` is opcode for the `call` instruction, the next `18 00 00 00` (note that address represented as little endian for the `x86_64`, in other words it is `00 00 00 18`) is the offset from the `callq` to the `factorial` function:
|
||||
|
||||
```python
|
||||
>>> hex(0x40051a + 0x18 + 0x5) == hex(0x400537)
|
||||
True
|
||||
```
|
||||
|
||||
So we add `0x18` and `0x5` to the address of the `call` instruction. The offset is measured from the address of the following instruction. Our call instruction is 5-bytes size - `e8 18 00 00 00` and the `0x18` is the offset from the next after call instruction to the `factorial` function. A compiler generally creates each object file with the program addresses starting at zero. But if a program is created from multiple object files, all of them will be overlapped. Just now we saw a process which is called `relocation`. This process assigns load addresses to the various parts of the program, adjusting the code and data in the program to reflect the assigned addresses.
|
||||
|
||||
Ok, now we know a little about linkers and relocation. Time to link our object files and to know more about linkers.
|
||||
|
||||
GNU linker
|
||||
-----------------
|
||||
|
||||
As you can understand from the title, I will use [GNU linker](https://en.wikipedia.org/wiki/GNU_linker) or just `ld` in this post. Of course we can use `gcc` to link our `factorial` project:
|
||||
|
||||
```
|
||||
$ gcc main.c lib.o -o factorial
|
||||
```
|
||||
|
||||
and after it we will get executable file - `factorial` as a result:
|
||||
|
||||
```
|
||||
./factorial
|
||||
factorial of 5 is: 120
|
||||
```
|
||||
|
||||
But `gcc` does not link object files. Instead it uses `collect2` which is just wrapper for the `GNU ld` linker:
|
||||
|
||||
```
|
||||
~$ /usr/lib/gcc/x86_64-linux-gnu/4.9/collect2 --version
|
||||
collect2 version 4.9.3
|
||||
/usr/bin/ld --version
|
||||
GNU ld (GNU Binutils for Debian) 2.25
|
||||
...
|
||||
...
|
||||
...
|
||||
```
|
||||
|
||||
Ok, we can use gcc and it will produce executable file of our program for us. But let's look how to use `GNU ld` linker for the same purpose. First of all let's try to link these object files with the following example:
|
||||
|
||||
```
|
||||
ld main.o lib.o -o factorial
|
||||
```
|
||||
|
||||
Try to do it and you will get following error:
|
||||
|
||||
```
|
||||
$ ld main.o lib.o -o factorial
|
||||
ld: warning: cannot find entry symbol _start; defaulting to 00000000004000b0
|
||||
main.o: In function `main':
|
||||
main.c:(.text+0x26): undefined reference to `printf'
|
||||
```
|
||||
|
||||
Here we can see two problems:
|
||||
|
||||
* Linker can't find `_start` symbol;
|
||||
* Linker does not know anything about `printf` function.
|
||||
|
||||
First of all let's try to understand what is this `_start` entry symbol that appears to be required for our program to run? When I started to learn programming I learned that the `main` function is the entry point of the program. I think you learned this too :) But it actually isn't the entry point, it's `_start` instead. The `_start` symbol is defined in the `crt1.o` object file. We can find it with the following command:
|
||||
|
||||
```
|
||||
$ objdump -S /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
|
||||
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: file format elf64-x86-64
|
||||
|
||||
|
||||
Disassembly of section .text:
|
||||
|
||||
0000000000000000 <_start>:
|
||||
0: 31 ed xor %ebp,%ebp
|
||||
2: 49 89 d1 mov %rdx,%r9
|
||||
...
|
||||
...
|
||||
...
|
||||
```
|
||||
|
||||
We pass this object file to the `ld` command as its first argument (see above). Now let's try to link it and will look on result:
|
||||
|
||||
```
|
||||
ld /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o \
|
||||
main.o lib.o -o factorial
|
||||
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: In function `_start':
|
||||
/tmp/buildd/glibc-2.19/csu/../sysdeps/x86_64/start.S:115: undefined reference to `__libc_csu_fini'
|
||||
/tmp/buildd/glibc-2.19/csu/../sysdeps/x86_64/start.S:116: undefined reference to `__libc_csu_init'
|
||||
/tmp/buildd/glibc-2.19/csu/../sysdeps/x86_64/start.S:122: undefined reference to `__libc_start_main'
|
||||
main.o: In function `main':
|
||||
main.c:(.text+0x26): undefined reference to `printf'
|
||||
```
|
||||
|
||||
Unfortunately we will see even more errors. We can see here old error about undefined `printf` and yet another three undefined references:
|
||||
|
||||
* `__libc_csu_fini`
|
||||
* `__libc_csu_init`
|
||||
* `__libc_start_main`
|
||||
|
||||
The `_start` symbol is defined in the [sysdeps/x86_64/start.S](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/start.S;h=0d27a38e9c02835ce17d1c9287aa01be222e72eb;hb=HEAD) assembly file in the `glibc` source code. We can find following assembly code lines there:
|
||||
|
||||
```assembly
|
||||
mov $__libc_csu_fini, %R8_LP
|
||||
mov $__libc_csu_init, %RCX_LP
|
||||
...
|
||||
call __libc_start_main
|
||||
```
|
||||
|
||||
Here we pass address of the entry point to the `.init` and `.fini` section that contain code that starts to execute when the program is ran and the code that executes when program terminates. And in the end we see the call of the `main` function from our program. These three symbols are defined in the [csu/elf-init.c](https://sourceware.org/git/?p=glibc.git;a=blob;f=csu/elf-init.c;hb=1d4bbc54bd4f7d85d774871341b49f4357af1fb7) source code file. The following two object files:
|
||||
|
||||
* `crtn.o`;
|
||||
* `crtn.i`.
|
||||
|
||||
define the function prologs/epilogs for the .init and .fini sections (with the `_init` and `_fini` symbols respectively).
|
||||
|
||||
The `crtn.o` object file contains these `.init` and `.fini` sections:
|
||||
|
||||
```
|
||||
$ objdump -S /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
|
||||
|
||||
0000000000000000 <.init>:
|
||||
0: 48 83 c4 08 add $0x8,%rsp
|
||||
4: c3 retq
|
||||
|
||||
Disassembly of section .fini:
|
||||
|
||||
0000000000000000 <.fini>:
|
||||
0: 48 83 c4 08 add $0x8,%rsp
|
||||
4: c3 retq
|
||||
```
|
||||
|
||||
And the `crti.o` object file contains the `_init` and `_fini` symbols. Let's try to link again with these two object files:
|
||||
|
||||
```
|
||||
$ ld \
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o \
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o \
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o main.o lib.o \
|
||||
-o factorial
|
||||
```
|
||||
|
||||
And anyway we will get the same errors. Now we need to pass `-lc` option to the `ld`. This option will search for the standard library in the paths present in the `$LD_LIBRARY_PATH` enviroment variable. Let's try to link again wit the `-lc` option:
|
||||
|
||||
```
|
||||
$ ld \
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o \
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o \
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o main.o lib.o -lc \
|
||||
-o factorial
|
||||
```
|
||||
|
||||
Finally we get an executable file, but if we try to run it, we will get strange results:
|
||||
|
||||
```
|
||||
$ ./factorial
|
||||
bash: ./factorial: No such file or directory
|
||||
```
|
||||
|
||||
What's the problem here? Let's look on the executable file with the [readelf](https://sourceware.org/binutils/docs/binutils/readelf.html) util:
|
||||
|
||||
```
|
||||
$ readelf -l factorial
|
||||
|
||||
Elf file type is EXEC (Executable file)
|
||||
Entry point 0x4003c0
|
||||
There are 7 program headers, starting at offset 64
|
||||
|
||||
Program Headers:
|
||||
Type Offset VirtAddr PhysAddr
|
||||
FileSiz MemSiz Flags Align
|
||||
PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040
|
||||
0x0000000000000188 0x0000000000000188 R E 8
|
||||
INTERP 0x00000000000001c8 0x00000000004001c8 0x00000000004001c8
|
||||
0x000000000000001c 0x000000000000001c R 1
|
||||
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
|
||||
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
|
||||
0x0000000000000610 0x0000000000000610 R E 200000
|
||||
LOAD 0x0000000000000610 0x0000000000600610 0x0000000000600610
|
||||
0x00000000000001cc 0x00000000000001cc RW 200000
|
||||
DYNAMIC 0x0000000000000610 0x0000000000600610 0x0000000000600610
|
||||
0x0000000000000190 0x0000000000000190 RW 8
|
||||
NOTE 0x00000000000001e4 0x00000000004001e4 0x00000000004001e4
|
||||
0x0000000000000020 0x0000000000000020 R 4
|
||||
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
|
||||
0x0000000000000000 0x0000000000000000 RW 10
|
||||
|
||||
Section to Segment mapping:
|
||||
Segment Sections...
|
||||
00
|
||||
01 .interp
|
||||
02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame
|
||||
03 .dynamic .got .got.plt .data
|
||||
04 .dynamic
|
||||
05 .note.ABI-tag
|
||||
06
|
||||
```
|
||||
|
||||
Note on the strange line:
|
||||
|
||||
```
|
||||
INTERP 0x00000000000001c8 0x00000000004001c8 0x00000000004001c8
|
||||
0x000000000000001c 0x000000000000001c R 1
|
||||
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
|
||||
```
|
||||
|
||||
The `.interp` section in the `elf` file holds the path name of a program interpreter or in another words the `.interp` section simply contains an `ascii` string that is the name of the dynamic linker. The dynamic linker is the part of Linux that loads and links shared libraries needed by an executable when it is executed, by copying the content of libraries from disk to RAM. As we can see in the output of the `readelf` command it is placed in the `/lib64/ld-linux-x86-64.so.2` file for the `x86_64` architecture. Now let's add the `-dynamic-linker` option with the path of `ld-linux-x86-64.so.2` to the `ld` call and will see the following results:
|
||||
|
||||
```
|
||||
$ gcc -c main.c lib.c
|
||||
|
||||
$ ld \
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o \
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o \
|
||||
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o main.o lib.o \
|
||||
-dynamic-linker /lib64/ld-linux-x86-64.so.2 \
|
||||
-lc -o factorial
|
||||
```
|
||||
|
||||
Now we can run it as normal executable file:
|
||||
|
||||
```
|
||||
$ ./factorial
|
||||
|
||||
factorial of 5 is: 120
|
||||
```
|
||||
|
||||
It works! With the first line we compile the `main.c` and the `lib.c` source code files to object files. We will get the `main.o` and the `lib.o` after execution of the `gcc`:
|
||||
|
||||
```
|
||||
$ file lib.o main.o
|
||||
lib.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
|
||||
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
|
||||
```
|
||||
|
||||
and after this we link object files of our program with the needed system object files and libraries. We just saw a simple example of how to compile and link a C program with the `gcc` compiler and `GNU ld` linker. In this example we have used a couple command line options of the `GNU linker`, but it supports much more command line options than `-o`, `-dynamic-linker`, etc... Moreover `GNU ld` has its own language that allows to control the linking process. In the next two paragraphs we will look into it.
|
||||
|
||||
Useful command line options of the GNU linker
|
||||
----------------------------------------------
|
||||
|
||||
As I already wrote and as you can see in the manual of the `GNU linker`, it has big set of the command line options. We've seen a couple of options in this post: `-o <output>` - that tells `ld` to produce an output file called `output` as the result of linking, `-l<name>` that adds the archive or object file specified by the name, `-dynamic-linker` that specifies the name of the dynamic linker. Of course `ld` supports much more command line options, let's look at some of them.
|
||||
|
||||
The first useful command line option is `@file`. In this case the `file` specifies filename where command line options will be read. For example we can create file with the name `linker.ld`, put there our command line arguments from the previous example and execute it with:
|
||||
|
||||
```
|
||||
$ ld @linker.ld
|
||||
```
|
||||
|
||||
The next command line option is `-b` or `--format`. This command line option specifies format of the input object files `ELF`, `DJGPP/COFF` and etc. There is a command line option for the same purpose but for the output file: `--oformat=output-format`.
|
||||
|
||||
The next command line option is `--defsym`. Full format of this command line option is the `--defsym=symbol=expression`. It allows to create global symbol in the output file containing the absolute address given by expression. We can find following case where this command line option can be useful: in the Linux kernel source code and more precisely in the Makefile that is related to the kernel decompression for the ARM architecture - [arch/arm/boot/compressed/Makefile](https://github.com/torvalds/linux/blob/master/arch/arm/boot/compressed/Makefile), we can find following definition:
|
||||
|
||||
```
|
||||
LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ)
|
||||
```
|
||||
|
||||
As we already know, it defines the `_kernel_bss_size` symbol with the size of the `.bss` section in the output file. This symbol will be used in the first [assembly file](https://github.com/torvalds/linux/blob/master/arch/arm/boot/compressed/head.S) that will be executed during kernel decompressing:
|
||||
|
||||
```assembly
|
||||
ldr r5, =_kernel_bss_size
|
||||
```
|
||||
|
||||
The next command line options is the `-shared` that allows us to create shared library. The `-M` or `-map <filename>` command line option prints the linking map with the information about symbols. In our case:
|
||||
|
||||
```
|
||||
$ ld -M @linker.ld
|
||||
...
|
||||
...
|
||||
...
|
||||
.text 0x00000000004003c0 0x112
|
||||
*(.text.unlikely .text.*_unlikely .text.unlikely.*)
|
||||
*(.text.exit .text.exit.*)
|
||||
*(.text.startup .text.startup.*)
|
||||
*(.text.hot .text.hot.*)
|
||||
*(.text .stub .text.* .gnu.linkonce.t.*)
|
||||
.text 0x00000000004003c0 0x2a /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
|
||||
...
|
||||
...
|
||||
...
|
||||
.text 0x00000000004003ea 0x31 main.o
|
||||
0x00000000004003ea main
|
||||
.text 0x000000000040041b 0x3f lib.o
|
||||
0x000000000040041b factorial
|
||||
```
|
||||
|
||||
Of course the `GNU linker` support standard command line options: `--help` and `--version` that print common help of the usage of the `ld` and its version. That's all about command line options of the `GNU linker`. Of course it is not the full set of command line options supported by the `ld` util. You can find the complete documentation of the `ld` util in the manual.
|
||||
|
||||
Control Language linker
|
||||
----------------------------------------------
|
||||
|
||||
As I wrote previously, `ld` has support for its own language. It accepts Linker Command Language files written in a superset of AT&T's Link Editor Command Language syntax, to provide explicit and total control over the linking process. Let's look on its details.
|
||||
|
||||
With the linker language we can control:
|
||||
|
||||
* input files;
|
||||
* output files;
|
||||
* file formats
|
||||
* addresses of sections;
|
||||
* etc...
|
||||
|
||||
Commands written in the linker control language are usually placed in a file called linker script. We can pass it to `ld` with the `-T` command line option. The main command in a linker script is the `SECTIONS` command. Each linker script must contain this command and it determines the `map` of the output file. The special variable `.` contains current position of the output. Let's write simple assembly program andi we will look at how we can use a linker script to control linking of this program. We will take a hello world program for this example:
|
||||
|
||||
```assembly
|
||||
section .data
|
||||
msg db "hello, world!",`\n`
|
||||
section .text
|
||||
global _start
|
||||
_start:
|
||||
mov rax, 1
|
||||
mov rdi, 1
|
||||
mov rsi, msg
|
||||
mov rdx, 14
|
||||
syscall
|
||||
mov rax, 60
|
||||
mov rdi, 0
|
||||
syscall
|
||||
```
|
||||
|
||||
We can compile and link it with the following commands:
|
||||
|
||||
```
|
||||
$ nasm -f elf64 -o hello.o hello.asm
|
||||
$ ld -o hello hello.o
|
||||
```
|
||||
|
||||
Our program consists from two sections: `.text` contains code of the program and `.data` contains initialized variables. Let's write simple linker script and try to link our `hello.asm` assembly file with it. Our script is:
|
||||
|
||||
```
|
||||
/*
|
||||
* Linker script for the factorial
|
||||
*/
|
||||
OUTPUT(hello)
|
||||
OUTPUT_FORMAT("elf64-x86-64")
|
||||
INPUT(hello.o)
|
||||
|
||||
SECTIONS
|
||||
{
|
||||
. = 0x200000;
|
||||
.text : {
|
||||
*(.text)
|
||||
}
|
||||
|
||||
. = 0x400000;
|
||||
.data : {
|
||||
*(.data)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
On the first three lines you can see a comment written in `C` style. After it the `OUTPUT` and the `OUTPUT_FORMAT` commands specifiy the name of our executable file and its format. The next command, `INPUT`, specfies the input file to the `ld` linker. Then, we can see the main `SECTIONS` command, which, as I already wrote, must be present in every linker script. The `SECTIONS` command represents the set and order of the sections which will be in the output file. At the beginning of the `SECTIONS` command we can see following line `. = 0x200000`. I already wrote above that `.` command points to the current position of the output. This line says that the code should be loaded at address `0x200000` and the line `. = 0x400000` says that data section should be loaded at address `0x400000`. The second line after the `. = 0x200000` defines `.text` as an output section. We can see `*(.text)` expression inside it. The `*` symbol is wildcard that matches any file name. In other words, the `*(.text)` expression says all `.text` input sections in all input files. We can rewrite it as `hello.o(.text)` for our example. After the following location counter `. = 0x400000`, we can see definition of the data section.
|
||||
|
||||
We can compile and link it with the:
|
||||
|
||||
```
|
||||
$ nasm -f elf64 -o hello.o hello.S && ld -T linker.script && ./hello
|
||||
hello, world!
|
||||
```
|
||||
|
||||
If we will look insidei it with the `objdump` util, we can see that `.text` section starts from the address `0x200000` and the `.data` sections starts from the address `0x400000`:
|
||||
|
||||
```
|
||||
$ objdump -D hello
|
||||
|
||||
Disassembly of section .text:
|
||||
|
||||
0000000000200000 <_start>:
|
||||
200000: b8 01 00 00 00 mov $0x1,%eax
|
||||
...
|
||||
|
||||
Disassembly of section .data:
|
||||
|
||||
0000000000400000 <msg>:
|
||||
400000: 68 65 6c 6c 6f pushq $0x6f6c6c65
|
||||
...
|
||||
```
|
||||
|
||||
Apart from the commands we have already seen, there are a few others. The first is the `ASSERT(exp, message)` that ensures that given expression is not zero. If it is zero, then exit the linker with an error code and print the given error message. If you've read about Linux kernel booting process in the [linux-insides](http://0xax.gitbooks.io/linux-insides/content/) book, you may know that the setup header of the Linux kernel has offset `0x1f1`. In the linker script of the Linux kernel we can find a check for this:
|
||||
|
||||
```
|
||||
. = ASSERT(hdr == 0x1f1, "The setup header has the wrong offset!");
|
||||
```
|
||||
|
||||
The `INCLUDE filename` command allows to include external linker script symbols in the current one. In a linker script we can assign a value to a symbol. `ld` supports a couple of assignment operators:
|
||||
|
||||
* symbol = expression ;
|
||||
* symbol += expression ;
|
||||
* symbol -= expression ;
|
||||
* symbol *= expression ;
|
||||
* symbol /= expression ;
|
||||
* symbol <<= expression ;
|
||||
* symbol >>= expression ;
|
||||
* symbol &= expression ;
|
||||
* symbol |= expression ;
|
||||
|
||||
As you can note all operators are C assignment operators. For example we can use it in our linker script as:
|
||||
|
||||
```
|
||||
START_ADDRESS = 0x200000;
|
||||
DATA_OFFSET = 0x200000;
|
||||
|
||||
SECTIONS
|
||||
{
|
||||
. = START_ADDRESS;
|
||||
.text : {
|
||||
*(.text)
|
||||
}
|
||||
|
||||
. = START_ADDRESS + DATA_OFFSET;
|
||||
.data : {
|
||||
*(.data)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
As you already may noted the syntax for expressions in the linker script language is identical to that of C expressions. Besides this the control language of the linking supports following builtin functions:
|
||||
|
||||
* `ABSOLUTE` - returns absolute value of the given expression;
|
||||
* `ADDR` - takes the section and returns its address;
|
||||
* `ALIGN` - returns the value of the location counter (`.` operator) that aligned by the boundary of the next expression after the given expression;
|
||||
* `DEFINED` - returns `1` if the given symbol placed in the global symbol table and `0` in other way;
|
||||
* `MAX` and `MIN` - return maximum and minimum of the two given expressions;
|
||||
* `NEXT` - returns the next unallocated address that is a multiple of the give expression;
|
||||
* `SIZEOF` - returns the size in bytes of the given named section.
|
||||
|
||||
That's all.
|
||||
|
||||
Conclusion
|
||||
-----------------
|
||||
|
||||
This is the end of the post about linkers. We learned many things about linkers in this post, such as what is a linker and why it is needed, how to use it, etc..
|
||||
|
||||
If you have any questions or suggestions, write me an [email](kuleshovmail@gmail.com) or ping [me](https://twitter.com/0xAX) on twitter.
|
||||
|
||||
Please note that English is not my first language, and I am really sorry for any inconvenience. If you find any mistakes please let me know via email or send a PR.
|
||||
|
||||
Links
|
||||
-----------------
|
||||
|
||||
* [Book about Linux kernel internals](http://0xax.gitbooks.io/linux-insides/content/)
|
||||
* [linker](https://en.wikipedia.org/wiki/Linker_%28computing%29)
|
||||
* [object files](https://en.wikipedia.org/wiki/Object_file)
|
||||
* [glibc](https://en.wikipedia.org/wiki/GNU_C_Library)
|
||||
* [opcode](https://en.wikipedia.org/wiki/Opcode)
|
||||
* [ELF](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format)
|
||||
* [GNU linker](https://en.wikipedia.org/wiki/GNU_linker)
|
||||
* [My posts about assembly programming for x86_64](http://0xax.github.io/categories/assembly/)
|
||||
* [readelf](https://sourceware.org/binutils/docs/binutils/readelf.html)
|
||||
@ -0,0 +1,515 @@
|
||||
Interrupts and Interrupt Handling. Part 9.
|
||||
================================================================================
|
||||
|
||||
Introduction to deferred interrupts (Softirq, Tasklets and Workqueues)
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
It is the ninth part of the [linux-insides](https://www.gitbook.com/book/0xax/linux-insides/details) book and in the previous [Previous part](http://0xax.gitbooks.io/linux-insides/content/interrupts/interrupts-8.html) we saw implementation of the `init_IRQ` from that defined in the [arch/x86/kernel/irqinit.c](https://github.com/torvalds/linux/blob/master/arch/x86/kernel/irqinit.c) source code file. So, we will continue to dive into the initialization stuff which is related to the external hardware interrupts in this part.
|
||||
|
||||
After the `init_IRQ` function we can see the call of the `softirq_init` function in the [init/main.c](https://github.com/torvalds/linux/blob/master/init/main.c). This function defined in the [kernel/softirq.c](https://github.com/torvalds/linux/blob/master/kernel/softirq.c) source code file and as we can understand from its name, this function makes initialization of the `softirq` or in other words initialization of the `deferred interrupts`. What is it deferreed intrrupt? We already saw a little bit about it in the ninth [part](http://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-9.html) of the chapter that describes initialization process of the Linux kernel. There are three types of `deffered interrupts` in the Linux kernel:
|
||||
|
||||
* `softirqs`;
|
||||
* `tasklets`;
|
||||
* `workqueues`;
|
||||
|
||||
And we will see description of all of these types in this part. As I said, we saw only a little bit about this theme, so, now is time to dive deep into details about this theme.
|
||||
|
||||
Deferred interrupts
|
||||
----------------------------------------------------------------------------------
|
||||
|
||||
Interrupts may have different important characteristics and there are two among them:
|
||||
|
||||
* Handler of an interrupt must execute quickly;
|
||||
* Sometime an interrupt handler must do a large amount of work.
|
||||
|
||||
As you can understand, it is almost impossible to make so that both characteristics were valid. Because of these, previously the handling of interrupts was splitted into two parts:
|
||||
|
||||
* Top half;
|
||||
* Bottom half;
|
||||
|
||||
Once the Linux kernel was one of the ways the organization postprocessing, and which was called: `the bottom half` of the processor, but now it is already not actual. Now this term has remained as a common noun referring to all the different ways of organizing deffered processing of an interrupt. With the advent of parallelisms in the Linux kernel, all new schemes of implementation of the bottom half handlers are built on the performance of the processor specific kernel thread that called `ksoftirqd` (will be discussed below). The `softirq` mechanism represents handling of interrupts that are `almost` as important as the handling of the hardware interrupts. The deferred processing of an interrupt suggests that some of the actions for an interrupt may be postponed to a later execution when the system will be less loaded. As you can suggests, an interrupt handler can do large amount of work that is impermissible as it executes in the context where interrupts are disabled. That's why processing of an interrupt can be splitted on two different parts. In the first part, the main handler of an interrupt does only minimal and the most important job. After this it schedules the second part and finishes its work. When the system is less busy and context of the processor allows to handle interrupts, the second part starts its work and finishes to process remaing part of a deferred interrupt. That is main explanation of the deferred interrupt handling.
|
||||
|
||||
As I already wrote above, handling of deferred interrupts (or `softirq` in other words) and accordingly `tasklets` is performed by a set of the special kernel threads (one thread per processor). Each processor has its own thread that is called `ksoftirqd/n` where the `n` is the number of the processor. We can see it in the output of the `systemd-cgls` util:
|
||||
|
||||
```
|
||||
$ systemd-cgls -k | grep ksoft
|
||||
├─ 3 [ksoftirqd/0]
|
||||
├─ 13 [ksoftirqd/1]
|
||||
├─ 18 [ksoftirqd/2]
|
||||
├─ 23 [ksoftirqd/3]
|
||||
├─ 28 [ksoftirqd/4]
|
||||
├─ 33 [ksoftirqd/5]
|
||||
├─ 38 [ksoftirqd/6]
|
||||
├─ 43 [ksoftirqd/7]
|
||||
```
|
||||
|
||||
The `spawn_ksoftirqd` function starts this these threads. As we can see this function called as early [initcall](http://www.compsoc.man.ac.uk/~moz/kernelnewbies/documents/initcall/index.html):
|
||||
|
||||
```C
|
||||
early_initcall(spawn_ksoftirqd);
|
||||
```
|
||||
|
||||
Deferred interrupts are determined statically at compile-time of the Linux kernel and the `open_softirq` function takes care of `softirq` initialization. The `open_softirq` function defined in the [kernel/softirq.c](https://github.com/torvalds/linux/blob/master/kernel/softirq.c):
|
||||
|
||||
|
||||
```C
|
||||
void open_softirq(int nr, void (*action)(struct softirq_action *))
|
||||
{
|
||||
softirq_vec[nr].action = action;
|
||||
}
|
||||
```
|
||||
|
||||
and as we can see this function uses two parameters:
|
||||
|
||||
* the index of the `softirq_vec` array;
|
||||
* a pointer to the softirq function to be executed;
|
||||
|
||||
First of all let's look on the `softirq_vec` array:
|
||||
|
||||
```C
|
||||
static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp;
|
||||
```
|
||||
|
||||
it defined in the same source code file. As we can see, the `softirq_vec` array may contain `NR_SOFTIRQS` or `10` types of `softirqs` that has type `softirq_action`. First of all about its elements. In the current version of the Linux kernel there are ten softirq vectors defined; two for tasklet processing, two for networking, two for the block layer, two for timers, and one each for the scheduler and read-copy-update processing. All of these kinds are represented by the following enum:
|
||||
|
||||
```C
|
||||
enum
|
||||
{
|
||||
HI_SOFTIRQ=0,
|
||||
TIMER_SOFTIRQ,
|
||||
NET_TX_SOFTIRQ,
|
||||
NET_RX_SOFTIRQ,
|
||||
BLOCK_SOFTIRQ,
|
||||
BLOCK_IOPOLL_SOFTIRQ,
|
||||
TASKLET_SOFTIRQ,
|
||||
SCHED_SOFTIRQ,
|
||||
HRTIMER_SOFTIRQ,
|
||||
RCU_SOFTIRQ,
|
||||
NR_SOFTIRQS
|
||||
};
|
||||
```
|
||||
|
||||
All names of these kinds of softirqs are represented by the following array:
|
||||
|
||||
```C
|
||||
const char * const softirq_to_name[NR_SOFTIRQS] = {
|
||||
"HI", "TIMER", "NET_TX", "NET_RX", "BLOCK", "BLOCK_IOPOLL",
|
||||
"TASKLET", "SCHED", "HRTIMER", "RCU"
|
||||
};
|
||||
```
|
||||
|
||||
Or we can see it in the output of the `/proc/softirqs`:
|
||||
|
||||
```
|
||||
~$ cat /proc/softirqs
|
||||
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
|
||||
HI: 5 0 0 0 0 0 0 0
|
||||
TIMER: 332519 310498 289555 272913 282535 279467 282895 270979
|
||||
NET_TX: 2320 0 0 2 1 1 0 0
|
||||
NET_RX: 270221 225 338 281 311 262 430 265
|
||||
BLOCK: 134282 32 40 10 12 7 8 8
|
||||
BLOCK_IOPOLL: 0 0 0 0 0 0 0 0
|
||||
TASKLET: 196835 2 3 0 0 0 0 0
|
||||
SCHED: 161852 146745 129539 126064 127998 128014 120243 117391
|
||||
HRTIMER: 0 0 0 0 0 0 0 0
|
||||
RCU: 337707 289397 251874 239796 254377 254898 267497 256624
|
||||
```
|
||||
|
||||
As we can see the `softirq_vec` array has `softirq_action` types. This is the main data structure related to the `softirq` mechanism, so all `softirqs` represented by the `softirq_action` structure. The `softirq_action` structure consists a single field only: an action pointer to the softirq function:
|
||||
|
||||
```C
|
||||
struct softirq_action
|
||||
{
|
||||
void (*action)(struct softirq_action *);
|
||||
};
|
||||
```
|
||||
|
||||
So, after this we can understand that the `open_softirq` function fills the `softirq_vec` array with the given `softirq_action`. The registered deferred interrupt (with the call of the `open_softirq` function) for it to be queued for execution, it should be activated by the call of the `raise_softirq` function. This function takes only one parameter -- a softirq index `nr`. Let's look on its implementation:
|
||||
|
||||
```C
|
||||
void raise_softirq(unsigned int nr)
|
||||
{
|
||||
unsigned long flags;
|
||||
|
||||
local_irq_save(flags);
|
||||
raise_softirq_irqoff(nr);
|
||||
local_irq_restore(flags);
|
||||
}
|
||||
```
|
||||
|
||||
Here we can see the call of the `raise_softirq_irqoff` function between the `local_irq_save` and the `local_irq_restore` macros. The `local_irq_save` defined in the [include/linux/irqflags.h](https://github.com/torvalds/linux/blob/master/include/linux/irqflags.h) header file and saves the state of the [IF](https://en.wikipedia.org/wiki/Interrupt_flag) flag of the [eflags](https://en.wikipedia.org/wiki/FLAGS_register) register and disables interrupts on the local processor. The `local_irq_restore` macro defined in the same header file and does the opposite thing: restores the `interrupt flag` and enables interrupts. We disable interrupts here because a `softirq` interrupt runs in the interrupt context and that one softirq (and no others) will be run.
|
||||
|
||||
The `raise_softirq_irqoff` function marks the softirq as deffered by setting the bit corresponding to the given index `nr` in the `softirq` bit mask (`__softirq_pending`) of the local processor. It does it with the help of the:
|
||||
|
||||
```C
|
||||
__raise_softirq_irqoff(nr);
|
||||
```
|
||||
|
||||
macro. After this, it checks the result of the `in_interrupt` that returns `irq_count` value. We already saw the `irq_count` in the first [part](http://0xax.gitbooks.io/linux-insides/content/interrupts/interrupts-1.html) of this chapter and it is used to check if a CPU is already on an interrupt stack or not. We just exit from the `raise_softirq_irqoff`, restore `IF` flang and enable interrupts on the local processor, if we are in the interrupt context, otherwise we call the `wakeup_softirqd`:
|
||||
|
||||
```C
|
||||
if (!in_interrupt())
|
||||
wakeup_softirqd();
|
||||
```
|
||||
|
||||
Where the `wakeup_softirqd` function activates the `ksoftirqd` kernel thread of the local processor:
|
||||
|
||||
```C
|
||||
static void wakeup_softirqd(void)
|
||||
{
|
||||
struct task_struct *tsk = __this_cpu_read(ksoftirqd);
|
||||
|
||||
if (tsk && tsk->state != TASK_RUNNING)
|
||||
wake_up_process(tsk);
|
||||
}
|
||||
```
|
||||
|
||||
Each `ksoftirqd` kernel thread runs the `run_ksoftirqd` function that checks existence of deferred interrupts and calls the `__do_softirq` function depends on result. This function reads the `__softirq_pending` softirq bit mask of the local processor and executes the deferrable functions corresponding to every bit set. During execution of a deferred function, new pending `softirqs` might occur. The main problem here that execution of the userspace code can be delayed for a long time while the `__do_softirq` function will handle deferred interrupts. For this purpose, it has the limit of the time when it must be finsihed:
|
||||
|
||||
```C
|
||||
unsigned long end = jiffies + MAX_SOFTIRQ_TIME;
|
||||
...
|
||||
...
|
||||
...
|
||||
restart:
|
||||
while ((softirq_bit = ffs(pending))) {
|
||||
...
|
||||
h->action(h);
|
||||
...
|
||||
}
|
||||
...
|
||||
...
|
||||
...
|
||||
pending = local_softirq_pending();
|
||||
if (pending) {
|
||||
if (time_before(jiffies, end) && !need_resched() &&
|
||||
--max_restart)
|
||||
goto restart;
|
||||
}
|
||||
...
|
||||
```
|
||||
|
||||
Checks of the existence of the deferred interrupts performed periodically and there are some points where this check occurs. The main point where this situation occurs is the call of the `do_IRQ` function that defined in the [arch/x86/kernel/irq.c](https://github.com/torvalds/linux/blob/master/arch/x86/kernel/irq.c) and provides main possibilities for actual interrupt processing in the Linux kernel. When this function will finish to handle an interrupt, it calls the `exiting_irq` function from the [arch/x86/include/asm/apic.h](https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/apic.h) that expands to the call of the `irq_exit` function. The `irq_exit` checks deferred interrupts, current context and calls the `invoke_softirq` function:
|
||||
|
||||
```C
|
||||
if (!in_interrupt() && local_softirq_pending())
|
||||
invoke_softirq();
|
||||
```
|
||||
|
||||
that executes the `__do_softirq` too. So what do we have in summary. Each `softirq` goes through the following stages: Registration of a `softirq` with the `open_softirq` function. Activation of a `softirq` by marking it as deferred with the `raise_softirq` function. After this, all marked `softirqs` will be runned in the next time the Linux kernel schedules a round of executions of deferrable functions. And execution of the deferred functions that have the same type.
|
||||
|
||||
As I already wrote, the `softirqs` are statically allocated and it is a problem for a kernel module that can be loaded. The second concept that built on top of `softirq` -- the `tasklets` solves this problem.
|
||||
|
||||
Tasklets
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
If you read the source code of the Linux kernel that is related to the `softirq`, you notice that it is used very rarely. The preferable way to implement deferrable functions are `tasklets`. As I already wrote above the `tasklets` are built on top of the `softirq` concept and generally on top of two `softirqs`:
|
||||
|
||||
* `TASKLET_SOFTIRQ`;
|
||||
* `HI_SOFTIRQ`.
|
||||
|
||||
In short words, `tasklets` are `softirqs` that can be allocated and initialized at runtime and unlike `softirqs`, tasklets that have the same type cannot be run on multiple processors at a time. Ok, now we know a little bit about the `softirqs`, of course previous text does not cover all aspects about this, but now we can directly look on the code and to know more about the `softirqs` step by step on practice and to know about `tasklets`. Let's return back to the implementation of the `softirq_init` function that we talked about in the beginning of this part. This function is defined in the [kernel/softirq.c](https://github.com/torvalds/linux/blob/master/kernel/softirq.c) source code file, let's look on its implementation:
|
||||
|
||||
```C
|
||||
void __init softirq_init(void)
|
||||
{
|
||||
int cpu;
|
||||
|
||||
for_each_possible_cpu(cpu) {
|
||||
per_cpu(tasklet_vec, cpu).tail =
|
||||
&per_cpu(tasklet_vec, cpu).head;
|
||||
per_cpu(tasklet_hi_vec, cpu).tail =
|
||||
&per_cpu(tasklet_hi_vec, cpu).head;
|
||||
}
|
||||
|
||||
open_softirq(TASKLET_SOFTIRQ, tasklet_action);
|
||||
open_softirq(HI_SOFTIRQ, tasklet_hi_action);
|
||||
}
|
||||
```
|
||||
|
||||
We can see definition of the integer `cpu` variable at the beginning of the `softirq_init` function. Next we will use it as parameter for the `for_each_possible_cpu` macro that goes through the all possible processors in the system. If the `possible processor` is the new terminology for you, you can read more about it the [CPU masks](http://0xax.gitbooks.io/linux-insides/content/Concepts/cpumask.html) chapter. In short words, `possible cpus` is the set of processors that can be plugged in anytime during the life of that system boot. All `possible processors` stored in the `cpu_possible_bits` bitmap, you can find its definition in the [kernel/cpu.c](https://github.com/torvalds/linux/blob/master/kernel/cpu.c):
|
||||
|
||||
```C
|
||||
static DECLARE_BITMAP(cpu_possible_bits, CONFIG_NR_CPUS) __read_mostly;
|
||||
...
|
||||
...
|
||||
...
|
||||
const struct cpumask *const cpu_possible_mask = to_cpumask(cpu_possible_bits);
|
||||
```
|
||||
|
||||
Ok, we defined the integer `cpu` variable and go through the all possible processors with the `for_each_possible_cpu` macro and makes initialization of the two following [per-cpu](http://0xax.gitbooks.io/linux-insides/content/Concepts/per-cpu.html) variables:
|
||||
|
||||
* `tasklet_vec`;
|
||||
* `tasklet_hi_vec`;
|
||||
|
||||
These two `per-cpu` variables defined in the same source [code](https://github.com/torvalds/linux/blob/master/kernel/softirq.c) file as the `softirq_init` function and represent two `tasklet_head` structures:
|
||||
|
||||
```C
|
||||
static DEFINE_PER_CPU(struct tasklet_head, tasklet_vec);
|
||||
static DEFINE_PER_CPU(struct tasklet_head, tasklet_hi_vec);
|
||||
```
|
||||
|
||||
Where `tasklet_head` structure represents a list of `Tasklets` and contains two fields, head and tail:
|
||||
|
||||
```C
|
||||
struct tasklet_head {
|
||||
struct tasklet_struct *head;
|
||||
struct tasklet_struct **tail;
|
||||
};
|
||||
```
|
||||
|
||||
The `tasklet_struct` structure is defined in the [include/linux/interrupt.h](https://github.com/torvalds/linux/blob/master/include/linux/interrupt.h) and represents the `Tasklet`. Previously we did not see this word in this book. Let's try to understand what the `tasklet` is. Actually, the tasklet is one of mechanisms to handle deferred interrupt. Let's look on the implementation of the `tasklet_struct` structure:
|
||||
|
||||
```C
|
||||
struct tasklet_struct
|
||||
{
|
||||
struct tasklet_struct *next;
|
||||
unsigned long state;
|
||||
atomic_t count;
|
||||
void (*func)(unsigned long);
|
||||
unsigned long data;
|
||||
};
|
||||
```
|
||||
|
||||
As we can see this structure contains five fields, they are:
|
||||
|
||||
* Next tasklet in the scheduling queue;
|
||||
* State of the tasklet;
|
||||
* Represent current state of the tasklet, active or not;
|
||||
* Main callback of the tasklet;
|
||||
* Parameter of the callback.
|
||||
|
||||
In our case, we set only for initialize only two arrays of tasklets in the `softirq_init` function: the `tasklet_vec` and the `tasklet_hi_vec`. Tasklets and high-priority tasklets are stored in the `tasklet_vec` and `tasklet_hi_vec` arrays, respectively. So, we have initialized these arrays and now we can see two calls of the `open_softirq` function that is defined in the [kernel/softirq.c](https://github.com/torvalds/linux/blob/master/kernel/softirq.c) source code file:
|
||||
|
||||
```C
|
||||
open_softirq(TASKLET_SOFTIRQ, tasklet_action);
|
||||
open_softirq(HI_SOFTIRQ, tasklet_hi_action);
|
||||
```
|
||||
|
||||
at the end of the `softirq_init` function. The main purpose of the `open_softirq` function is the initalization of `softirq`. Let's look on the implementation of the `open_softirq` function.
|
||||
|
||||
, in our case they are: `tasklet_action` and the `tasklet_hi_action` or the `softirq` function associated with the `HI_SOFTIRQ` softirq is named `tasklet_hi_action` and `softirq` function associated with the `TASKLET_SOFTIRQ` is named `tasklet_action`. The Linux kernel provides API for the manipulating of `tasklets`. First of all it is the `tasklet_init` function that takes `tasklet_struct`, function and parameter for it and initializes the given `tasklet_struct` with the given data:
|
||||
|
||||
```C
|
||||
void tasklet_init(struct tasklet_struct *t,
|
||||
void (*func)(unsigned long), unsigned long data)
|
||||
{
|
||||
t->next = NULL;
|
||||
t->state = 0;
|
||||
atomic_set(&t->count, 0);
|
||||
t->func = func;
|
||||
t->data = data;
|
||||
}
|
||||
```
|
||||
|
||||
There are additional methods to initialize a tasklet statically with the two following macros:
|
||||
|
||||
```C
|
||||
DECLARE_TASKLET(name, func, data);
|
||||
DECLARE_TASKLET_DISABLED(name, func, data);
|
||||
```
|
||||
|
||||
The Linux kernel provides three following functions to mark a tasklet as ready to run:
|
||||
|
||||
```C
|
||||
void tasklet_schedule(struct tasklet_struct *t);
|
||||
void tasklet_hi_schedule(struct tasklet_struct *t);
|
||||
void tasklet_hi_schedule_first(struct tasklet_struct *t);
|
||||
```
|
||||
|
||||
The first function schedules a tasklet with the normal priority, the second with the high priority and the third out of turn. Implementation of the all of these three functions is similar, so we will consider only the first -- `tasklet_schedule`. Let's look on its implementation:
|
||||
|
||||
```C
|
||||
static inline void tasklet_schedule(struct tasklet_struct *t)
|
||||
{
|
||||
if (!test_and_set_bit(TASKLET_STATE_SCHED, &t->state))
|
||||
__tasklet_schedule(t);
|
||||
}
|
||||
|
||||
void __tasklet_schedule(struct tasklet_struct *t)
|
||||
{
|
||||
unsigned long flags;
|
||||
|
||||
local_irq_save(flags);
|
||||
t->next = NULL;
|
||||
*__this_cpu_read(tasklet_vec.tail) = t;
|
||||
__this_cpu_write(tasklet_vec.tail, &(t->next));
|
||||
raise_softirq_irqoff(TASKLET_SOFTIRQ);
|
||||
local_irq_restore(flags);
|
||||
}
|
||||
```
|
||||
|
||||
As we can see it checks and sets the state of the given tasklet to the `TASKLET_STATE_SCHED` and executes the `__tasklet_schedule` with the given tasklet. The `__tasklet_schedule` looks very similar to the `raise_softirq` function that we saw above. It saves the `interrupt flag` and disables interrupts at the beginning. After this, it updates `tasklet_vec` with the new tasklet and calls the `raise_softirq_irqoff` function that we saw above. When the Linux kernel scheduler will decide to run deferred functions, the `tasklet_action` function will be called for deferred functions which are associated with the `TASKLET_SOFTIRQ` and `tasklet_hi_action` for deferred functions which are associated with the `HI_SOFTIRQ`. These functions are very similar and there is only one difference between them -- `tasklet_action` uses `tasklet_vec` and `tasklet_hi_action` uses `tasklet_hi_vec`.
|
||||
|
||||
Let's look on the implementation of the `tasklet_action` function:
|
||||
|
||||
```C
|
||||
static void tasklet_action(struct softirq_action *a)
|
||||
{
|
||||
local_irq_disable();
|
||||
list = __this_cpu_read(tasklet_vec.head);
|
||||
__this_cpu_write(tasklet_vec.head, NULL);
|
||||
__this_cpu_write(tasklet_vec.tail, this_cpu_ptr(&tasklet_vec.head));
|
||||
local_irq_enable();
|
||||
|
||||
while (list) {
|
||||
if (tasklet_trylock(t)) {
|
||||
t->func(t->data);
|
||||
tasklet_unlock(t);
|
||||
}
|
||||
...
|
||||
...
|
||||
...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In the beginning of the `tasketl_action` function, we disable interrupts for the local processor with the help of the `local_irq_disable` macro (you can read about this macro in the second [part](http://0xax.gitbooks.io/linux-insides/content/interrupts/interrupts-2.html) of this chapter). In the next step, we take a head of the list that contains tasklets with normal priority and set this per-cpu list to `NULL` because all tasklets must be executed in a generaly way. After this we enable interrupts for the local processor and go through the list of taklets in the loop. In every iteration of the loop we call the `tasklet_trylock` function for the given tasklet that updates state of the given tasklet on `TASKLET_STATE_RUN`:
|
||||
|
||||
```C
|
||||
static inline int tasklet_trylock(struct tasklet_struct *t)
|
||||
{
|
||||
return !test_and_set_bit(TASKLET_STATE_RUN, &(t)->state);
|
||||
}
|
||||
```
|
||||
|
||||
If this operation was successful we execute tasklet's action (it was set in the `tasklet_init`) and call the `tasklet_unlock` function that clears tasklet's `TASKLET_STATE_RUN` state.
|
||||
|
||||
In general, that's all about `tasklets` concept. Of course this does not cover full `tasklets`, but I think that it is a good point from where you can continue to learn this concept.
|
||||
|
||||
The `tasklets` are [widely](http://lxr.free-electrons.com/ident?i=tasklet_init) used concept in the Linux kernel, but as I wrote in the beginning of this part there is third mechanism for deferred functions -- `workqueue`. In the next paragraph we will see what it is.
|
||||
|
||||
Workqueues
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
The `workqueue` is another concept for handling deferred functions. It is similar to `tasklets` with some differences. Workqueue functions run in the context of a kernel process, but `tasklet` functions run in the software interrupt context. This means that `workqueue` functions must not be atomic as `tasklet` functions. Tasklets always run on the processor from which they were originally submitted. Workqueues work in the same way, but only by default. The `workqueue` concept represented by the:
|
||||
|
||||
```C
|
||||
struct worker_pool {
|
||||
spinlock_t lock;
|
||||
int cpu;
|
||||
int node;
|
||||
int id;
|
||||
unsigned int flags;
|
||||
|
||||
struct list_head worklist;
|
||||
int nr_workers;
|
||||
...
|
||||
...
|
||||
...
|
||||
```
|
||||
|
||||
structure that is defined in the [kernel/workqueue.c](https://github.com/torvalds/linux/blob/master/kernel/workqueue.c) source code file in the Linux kernel. I will not write the source code of this structure here, because it has quite a lot of fields, but we will consider some of those fields.
|
||||
|
||||
In its most basic form, the work queue subsystem is an interface for creating kernel threads to handle work that is queued from elsewhere. All of these kernel threads are called -- `worker threads`. The work queue are maintained by the `work_struct` that defined in the [include/linux/workqueue.h](https://github.com/torvalds/linux/blob/master/include/linux/workqueue.h). Let's look on this structure:
|
||||
|
||||
```C
|
||||
struct work_struct {
|
||||
atomic_long_t data;
|
||||
struct list_head entry;
|
||||
work_func_t func;
|
||||
#ifdef CONFIG_LOCKDEP
|
||||
struct lockdep_map lockdep_map;
|
||||
#endif
|
||||
};
|
||||
```
|
||||
|
||||
Here are two things that we are interested: `func` -- the function that will be scheduled by the `workqueue` and the `data` - parameter of this function. The Linux kernel provides special per-cpu threads that are called `kworker`:
|
||||
|
||||
```
|
||||
systemd-cgls -k | grep kworker
|
||||
├─ 5 [kworker/0:0H]
|
||||
├─ 15 [kworker/1:0H]
|
||||
├─ 20 [kworker/2:0H]
|
||||
├─ 25 [kworker/3:0H]
|
||||
├─ 30 [kworker/4:0H]
|
||||
...
|
||||
...
|
||||
...
|
||||
```
|
||||
|
||||
This process can be used to schedule the deferred functions of the workqueues (as `ksoftirqd` for `softirqs`). Besides this we can create new separate worker thread for a `workqueue`. The Linux kernel provides following macros for the creation of workqueue:
|
||||
|
||||
```C
|
||||
#define DECLARE_WORK(n, f) \
|
||||
struct work_struct n = __WORK_INITIALIZER(n, f)
|
||||
```
|
||||
|
||||
for static creation. It takes two parameters: name of the workqueue and the workqueue function. For creation of workqueue in runtime, we can use the:
|
||||
|
||||
```C
|
||||
#define INIT_WORK(_work, _func) \
|
||||
__INIT_WORK((_work), (_func), 0)
|
||||
|
||||
#define __INIT_WORK(_work, _func, _onstack) \
|
||||
do { \
|
||||
__init_work((_work), _onstack); \
|
||||
(_work)->data = (atomic_long_t) WORK_DATA_INIT(); \
|
||||
INIT_LIST_HEAD(&(_work)->entry); \
|
||||
(_work)->func = (_func); \
|
||||
} while (0)
|
||||
```
|
||||
|
||||
macro that takes `work_struct` structure that has to be created and the function to be scheduled in this workqueue. After a `work` was created with the one of these macros, we need to put it to the `workqueue`. We can do it with the help of the `queue_work` or the `queue_delayed_work` functions:
|
||||
|
||||
```C
|
||||
static inline bool queue_work(struct workqueue_struct *wq,
|
||||
struct work_struct *work)
|
||||
{
|
||||
return queue_work_on(WORK_CPU_UNBOUND, wq, work);
|
||||
}
|
||||
```
|
||||
|
||||
The `queue_work` function just calls the `queue_work_on` function that queue work on specific processor. Note that in our case we pass the `WORK_STRUCT_PENDING_BIT` to the `queue_work_on` function. It is a part of the `enum` that is defined in the [include/linux/workqueue.h](https://github.com/torvalds/linux/blob/master/include/linux/workqueue.h) and represents workqueue which are not bound to any specific processor. The `queue_work_on` function tests and set the `WORK_STRUCT_PENDING_BIT` bit of the given `work` and executes the `__queue_work` function with the `workqueue` for the given processor and given `work`:
|
||||
|
||||
```C
|
||||
__queue_work(cpu, wq, work);
|
||||
```
|
||||
|
||||
The `__queue_work` function gets the `work pool`. Yes, the `work pool` not `workqueue`. Actually, all `works` are not placed in the `workqueue`, but to the `work pool` that is represented by the `worker_pool` structure in the Linux kernel. As you can see above, the `workqueue_struct` structure has the `pwqs` field which is list of `worker_pools`. When we create a `workqueue`, it stands out for each processor the `pool_workqueue`. Each `pool_workqueue` associated with `worker_pool`, which is allocated on the same processor and corresponds to the type of priority queue. Through them `workqueue` interacts with `worker_pool`. So in the `__queue_work` function we set the cpu to the current processor with the `raw_smp_processor_id` (you can find information about this marco in the fouth [part](http://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-4.html) of the Linux kernel initialization process chapter), getting the `pool_workqueue` for the given `workqueue_struct` and insert the given `work` to the given `workqueue`:
|
||||
|
||||
```C
|
||||
static void __queue_work(int cpu, struct workqueue_struct *wq,
|
||||
struct work_struct *work)
|
||||
{
|
||||
...
|
||||
...
|
||||
...
|
||||
if (req_cpu == WORK_CPU_UNBOUND)
|
||||
cpu = raw_smp_processor_id();
|
||||
|
||||
if (!(wq->flags & WQ_UNBOUND))
|
||||
pwq = per_cpu_ptr(wq->cpu_pwqs, cpu);
|
||||
else
|
||||
pwq = unbound_pwq_by_node(wq, cpu_to_node(cpu));
|
||||
...
|
||||
...
|
||||
...
|
||||
insert_work(pwq, work, worklist, work_flags);
|
||||
```
|
||||
|
||||
As we can create `works` and `workqueue`, we need to know when they are executed. As I already wrote, all `works` are executed by the kernel thread. When this kernel thread is scheduled, it starts to execute `works` from the given `workqueue`. Each worker thread executes a loop inside the `worker_thread` function. This thread makes many different things and part of these things are similar to what we saw before in this part. As it starts executing, it removes all `work_struct` or `works` from its `workqueue`.
|
||||
|
||||
That's all.
|
||||
|
||||
Conclusion
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
It is the end of the ninth part of the [Interrupts and Interrupt Handling](http://0xax.gitbooks.io/linux-insides/content/interrupts/index.html) chapter and we continued to dive into external hardware interrupts in this part. In the previous part we saw initialization of the `IRQs` and main `irq_desc` structure. In this part we saw three concepts: the `softirq`, `tasklet` and `workqueue` that are used for the deferred functions.
|
||||
|
||||
The next part will be last part of the `Interrupts and Interrupt Handling` chapter and we will look on the real hardware driver and will try to learn how it works with the interrupts subsystem.
|
||||
|
||||
If you have any questions or suggestions, write me a comment or ping me at [twitter](https://twitter.com/0xAX).
|
||||
|
||||
**Please note that English is not my first language, And I am really sorry for any inconvenience. If you find any mistakes please send me PR to [linux-internals](https://github.com/0xAX/linux-internals).**
|
||||
|
||||
Links
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
* [initcall](http://www.compsoc.man.ac.uk/~moz/kernelnewbies/documents/initcall/index.html)
|
||||
* [IF](https://en.wikipedia.org/wiki/Interrupt_flag)
|
||||
* [eflags](https://en.wikipedia.org/wiki/FLAGS_register)
|
||||
* [CPU masks](http://0xax.gitbooks.io/linux-insides/content/Concepts/cpumask.html)
|
||||
* [per-cpu](http://0xax.gitbooks.io/linux-insides/content/Concepts/per-cpu.html)
|
||||
* [Workqueue](https://github.com/torvalds/linux/blob/master/Documentation/workqueue.txt)
|
||||
* [Previous part](http://0xax.gitbooks.io/linux-insides/content/interrupts/interrupts-8.html)
|
||||
Loading…
Reference in new issue