mirror of
https://github.com/0xAX/linux-insides.git
synced 2024-12-21 22:28:08 +00:00
Merge pull request #818 from renaudgermain/copyedit-misc
copyedit: misc chapter
This commit is contained in:
0xAX
GitHub
commit
360fc7c129
@ -165,7 +165,7 @@ As result of compilation we can see the compressed kernel - `arch/x86/boot/bzIma
|
||||
Installing Linux kernel
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
As I already wrote we will consider two ways how to launch new kernel: In the first case we can install and run the new version of the Linux kernel on the real hardware and the second is launch the Linux kernel on a virtual machine. In the previous paragraph we saw how to build the Linux kernel from source code and as a result we have got compressed image:
|
||||
As I already wrote we will consider two ways to launch new kernel: in the first case we can install and run the new version of the Linux kernel on the real hardware and the second is launch the Linux kernel on a virtual machine. In the previous paragraph we saw how to build the Linux kernel from source code and as a result we have got compressed image:
|
||||
|
||||
```
|
||||
...
|
||||
@ -282,7 +282,7 @@ Consider using [ivandaviov/minimal](https://github.com/ivandavidov/minimal) or [
|
||||
Getting started with the Linux Kernel Development
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
The main point of this paragraph is to answer two questions: What to do and what not to do before sending your first patch to the Linux kernel. Please, do not confuse this `to do` with `todo`. I have no answer what you can fix in the Linux kernel. I just want to tell you my workflow during experimenting with the Linux kernel source code.
|
||||
The main point of this paragraph is to answer two questions: what to do and what not to do before sending your first patch to the Linux kernel. Please, do not confuse this `to do` with `todo`. I have no answer what you can fix in the Linux kernel. I just want to tell you my workflow during experimenting with the Linux kernel source code.
|
||||
|
||||
First of all I pull the latest updates from Linus's repo with the following commands:
|
||||
|
||||
|
||||
@ -110,7 +110,7 @@ The `C` option tells the `makefile` that we need to check all `c` source code wi
|
||||
ifeq ($(KBUILD_SRC),)
|
||||
srctree := .
|
||||
endif
|
||||
|
||||
|
||||
objtree := .
|
||||
src := $(srctree)
|
||||
obj := $(objtree)
|
||||
@ -250,7 +250,7 @@ all: vmlinux
|
||||
|
||||
Don't worry that we have missed many lines in Makefile that are between `export RCS_FIND_IGNORE.....` and `all: vmlinux.....`. This part of the makefile is responsible for the `make *.config` targets and as I wrote in the beginning of this part we will see only building of the kernel in a general way.
|
||||
|
||||
The `all:` target is the default when no target is given on the command line. You can see here that we include architecture specific makefile there (in our case it will be [arch/x86/Makefile](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/Makefile)). From this moment we will continue from this makefile. As we can see `all` target depends on the `vmlinux` target that defined a little lower in the top makefile:
|
||||
The `all:` target is the default when no target is given on the command line. You can see here that we include architecture specific makefile there (in our case it will be [arch/x86/Makefile](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/Makefile)). From this moment we will continue from this makefile. As we can see `all` target depends on the `vmlinux` target that is defined a little lower in the top makefile:
|
||||
|
||||
```Makefile
|
||||
vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE
|
||||
@ -302,7 +302,7 @@ prepare1: prepare2 $(version_h) include/generated/utsrelease.h \
|
||||
prepare2: prepare3 outputmakefile asm-generic
|
||||
```
|
||||
|
||||
The first `prepare0` expands to the `archprepare` that expands to the `archheaders` and `archscripts` that defined in the `x86_64` specific [Makefile](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/Makefile). Let's look on it. The `x86_64` specific makefile starts from the definition of the variables that are related to the architecture-specific configs ([defconfig](https://github.com/torvalds/linux/tree/master/arch/x86/configs), etc...). After this it defines flags for the compiling of the [16-bit](https://en.wikipedia.org/wiki/Real_mode) code, calculating of the `BITS` variable that can be `32` for `i386` or `64` for the `x86_64` flags for the assembly source code, flags for the linker and many many more (all definitions you can find in the [arch/x86/Makefile](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/Makefile)). The first target is `archheaders` in the makefile generates syscall table:
|
||||
The first `prepare0` expands to the `archprepare` that expands to the `archheaders` and `archscripts` that defined in the `x86_64` specific [Makefile](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/Makefile). Let's look on it. The `x86_64` specific makefile starts from the definition of the variables that are related to the architecture-specific configs ([defconfig](https://github.com/torvalds/linux/tree/master/arch/x86/configs), etc...). After this it defines flags for the compiling of the [16-bit](https://en.wikipedia.org/wiki/Real_mode) code, calculating of the `BITS` variable that can be `32` for `i386` or `64` for the `x86_64` flags for the assembly source code, flags for the linker and many many more (all definitions you can find in the [arch/x86/Makefile](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/Makefile)). The first target is `archheaders` in the makefile and it generates syscall table:
|
||||
|
||||
```Makefile
|
||||
archheaders:
|
||||
@ -425,7 +425,7 @@ $(vmlinux-dirs): prepare scripts
|
||||
$(Q)$(MAKE) $(build)=$@
|
||||
```
|
||||
|
||||
The `$@` represents `vmlinux-dirs` here that means that it will go recursively over all directories from the `vmlinux-dirs` and its internal directories (depens on configuration) and will execute `make` in there. We can see it in the output:
|
||||
The `$@` represents `vmlinux-dirs` here that means that it will go recursively over all directories from the `vmlinux-dirs` and its internal directories (depends on configuration) and will execute `make` in there. We can see it in the output:
|
||||
|
||||
```
|
||||
CC init/main.o
|
||||
|
||||
@ -39,7 +39,7 @@ The `lib.c` file contains:
|
||||
```C
|
||||
int factorial(int base) {
|
||||
int res,i = 1;
|
||||
|
||||
|
||||
if (base == 0) {
|
||||
return 1;
|
||||
}
|
||||
@ -107,8 +107,8 @@ Disassembly of section .text:
|
||||
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
|
||||
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 within the following `objdump` output:
|
||||
@ -169,7 +169,7 @@ factorial: file format elf64-x86-64
|
||||
...
|
||||
```
|
||||
|
||||
As we can see in the previous output, the address of the `main` function is `0x0000000000400506`. Why it does not start from `0x0`? You may already know that standard C programs are linked with the `glibc` C standard library (assuming the `-nostdlib` was not passed to the `gcc`). The compiled code for a program includes constructor 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 start from the code placed in the special `.init` section. We can see this in the beginning of the objdump output:
|
||||
As we can see in the previous output, the address of the `main` function is `0x0000000000400506`. Why doesn't it start from `0x0`? You may already know that standard C programs are linked with the `glibc` C standard library (assuming the `-nostdlib` was not passed to the `gcc`). The compiled code for a program includes constructor 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 start from the code placed in the special `.init` section. We can see this in the beginning of the objdump output:
|
||||
|
||||
```
|
||||
objdump -S factorial | less
|
||||
@ -215,7 +215,7 @@ $ gcc main.c lib.o -o factorial
|
||||
and after it we will get executable file - `factorial` as a result:
|
||||
|
||||
```
|
||||
./factorial
|
||||
./factorial
|
||||
factorial of 5 is: 120
|
||||
```
|
||||
|
||||
@ -312,13 +312,13 @@ $ 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
|
||||
4: c3 retq
|
||||
|
||||
Disassembly of section .fini:
|
||||
|
||||
0000000000000000 <.fini>:
|
||||
0: 48 83 c4 08 add $0x8,%rsp
|
||||
4: c3 retq
|
||||
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:
|
||||
@ -344,14 +344,14 @@ $ ld \
|
||||
Finally we get an executable file, but if we try to run it, we will get strange results:
|
||||
|
||||
```
|
||||
$ ./factorial
|
||||
$ ./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
|
||||
$ readelf -l factorial
|
||||
|
||||
Elf file type is EXEC (Executable file)
|
||||
Entry point 0x4003c0
|
||||
@ -378,13 +378,13 @@ Program Headers:
|
||||
|
||||
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
|
||||
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:
|
||||
@ -429,7 +429,7 @@ and after this we link object files of our program with the needed system object
|
||||
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.
|
||||
As I already wrote and as you can see in the manual of the `GNU linker`, it has a big set of 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:
|
||||
|
||||
@ -445,7 +445,7 @@ The next command line option is `--defsym`. Full format of this command line opt
|
||||
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/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/arm/boot/compressed/head.S) that will be executed during kernel decompressing:
|
||||
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/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/arm/boot/compressed/head.S) that will be executed during kernel decompression:
|
||||
|
||||
```assembly
|
||||
ldr r5, =_kernel_bss_size
|
||||
@ -474,7 +474,7 @@ $ ld -M @linker.ld
|
||||
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.
|
||||
Of course the `GNU linker` supports standard command line options: `--help` and `--version` that prints 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
|
||||
----------------------------------------------
|
||||
@ -524,7 +524,7 @@ Our program consists from two sections: `.text` contains code of the program and
|
||||
/*
|
||||
* Linker script for the factorial
|
||||
*/
|
||||
OUTPUT(hello)
|
||||
OUTPUT(hello)
|
||||
OUTPUT_FORMAT("elf64-x86-64")
|
||||
INPUT(hello.o)
|
||||
|
||||
@ -607,14 +607,14 @@ SECTIONS
|
||||
}
|
||||
```
|
||||
|
||||
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:
|
||||
As you already may have 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;
|
||||
* `DEFINED` - returns `1` if the given symbol placed in the global symbol table and `0` otherwise;
|
||||
* `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;
|
||||
* `NEXT` - returns the next unallocated address that is a multiple of the given expression;
|
||||
* `SIZEOF` - returns the size in bytes of the given named section.
|
||||
|
||||
That's all.
|
||||
|
||||
@ -4,9 +4,9 @@ Program startup process in userspace
|
||||
Introduction
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
Despite the [linux-insides](https://www.gitbook.com/book/0xax/linux-insides/details) described mostly Linux kernel related stuff, I have decided to write this one part which mostly related to userspace.
|
||||
Despite the [linux-insides](https://www.gitbook.com/book/0xax/linux-insides/details) described mostly Linux kernel related stuff, I have decided to write this one part which mostly relates to userspace.
|
||||
|
||||
There is already fourth [part](https://0xax.gitbook.io/linux-insides/summary/syscall/linux-syscall-4) of [System calls](https://en.wikipedia.org/wiki/System_call) chapter which describes what does the Linux kernel do when we want to start a program. In this part I want to explore what happens when we run a program on a Linux machine from userspace perspective.
|
||||
There is already fourth [part](https://0xax.gitbook.io/linux-insides/summary/syscall/linux-syscall-4) of [System calls](https://en.wikipedia.org/wiki/System_call) chapter which describes what the Linux kernel does when we want to start a program. In this part I want to explore what happens when we run a program on a Linux machine from userspace perspective.
|
||||
|
||||
I don't know how about you, but in my university I learn that a `C` program starts executing from the function which is called `main`. And that's partly true. Whenever we are starting to write new program, we start our program from the following lines of code:
|
||||
|
||||
@ -75,7 +75,7 @@ Note on `Entry point: 0x400430` line. Now we know the actual address of entry po
|
||||
(gdb) break *0x400430
|
||||
Breakpoint 1 at 0x400430
|
||||
(gdb) run
|
||||
Starting program: /home/alex/program
|
||||
Starting program: /home/alex/program
|
||||
|
||||
Breakpoint 1, 0x0000000000400430 in _start ()
|
||||
```
|
||||
@ -135,7 +135,7 @@ SYSCALL_DEFINE3(execve,
|
||||
}
|
||||
```
|
||||
|
||||
It takes an executable file name, set of command line arguments, and set of environment variables. As you may guess, everything is done by the `do_execve` function. I will not describe the implementation of the `do_execve` function in detail because you can read about this in [here](https://0xax.gitbook.io/linux-insides/summary/syscall/linux-syscall-4). But in short words, the `do_execve` function does many checks like `filename` is valid, limit of launched processes is not exceed in our system and etc. After all of these checks, this function parses our executable file which is represented in [ELF](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) format, creates memory descriptor for newly executed executable file and fills it with the appropriate values like area for the stack, heap and etc. When the setup of new binary image is done, the `start_thread` function will set up one new process. This function is architecture-specific and for the [x86_64](https://en.wikipedia.org/wiki/X86-64) architecture, its definition will be located in the [arch/x86/kernel/process_64.c](https://github.com/torvalds/linux/blob/08e4e0d0456d0ca8427b2d1ddffa30f1c3e774d7/arch/x86/kernel/process_64.c#L239) source code file.
|
||||
It takes an executable file name, set of command line arguments, and set of environment variables. As you may guess, everything is done by the `do_execve` function. I will not describe the implementation of the `do_execve` function in detail because you can read about this in [here](https://0xax.gitbook.io/linux-insides/summary/syscall/linux-syscall-4). But in short words, the `do_execve` function does many checks like `filename` is valid, limit of launched processes is not exceeded in our system and etc. After all of these checks, this function parses our executable file which is represented in [ELF](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) format, creates memory descriptor for newly executed executable file and fills it with the appropriate values like area for the stack, heap and etc. When the setup of new binary image is done, the `start_thread` function will set up one new process. This function is architecture-specific and for the [x86_64](https://en.wikipedia.org/wiki/X86-64) architecture, its definition will be located in the [arch/x86/kernel/process_64.c](https://github.com/torvalds/linux/blob/08e4e0d0456d0ca8427b2d1ddffa30f1c3e774d7/arch/x86/kernel/process_64.c#L239) source code file.
|
||||
|
||||
The `start_thread` function sets new value to [segment registers](https://en.wikipedia.org/wiki/X86_memory_segmentation) and program execution address. From this point, our new process is ready to start. Once the [context switch](https://en.wikipedia.org/wiki/Context_switch) will be done, control will be returned to userspace with new values of registers and the new executable will be started to execute.
|
||||
|
||||
@ -144,13 +144,13 @@ That's all from the kernel side. The Linux kernel prepares the binary image for
|
||||
How does a program start in userspace
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
In the previous paragraph we saw how an executable file is prepared to run by the Linux kernel. Let's look at the same, but from userspace side. We already know that the entry point of each program is its `_start` function. But where is this function from? It may came from a library. But if you remember correctly we didn't link our program with any libraries during compilation of our program:
|
||||
In the previous paragraph we saw how an executable file is prepared to run by the Linux kernel. Let's look at the same, but from userspace side. We already know that the entry point of each program is its `_start` function. But where is this function from? It may come from a library. But if you remember correctly we didn't link our program with any libraries during compilation of our program:
|
||||
|
||||
```
|
||||
$ gcc -Wall program.c -o sum
|
||||
```
|
||||
|
||||
You may guess that `_start` comes from the [standard library](https://en.wikipedia.org/wiki/Standard_library) and that's true. If you try to compile our program again and pass the `-v` option to gcc which will enable `verbose mode`, you will see a long output. The full output is not interesting for us, let's look at the following steps:
|
||||
You may guess that `_start` comes from the [standard library](https://en.wikipedia.org/wiki/Standard_library) and that's true. If you try to compile our program again and pass the `-v` option to gcc which will enable `verbose mode`, you will see a long output. The full output is not interesting for us, let's look at the following steps:
|
||||
|
||||
First of all, our program should be compiled with `gcc`:
|
||||
|
||||
@ -217,10 +217,10 @@ $ gcc -nostdlib -lc -ggdb program.c -o program
|
||||
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400350
|
||||
```
|
||||
|
||||
Ok, the compiler does not complain about undefined reference of standard library functions anymore as we linked our program with `/usr/lib64/libc.so.6`, but the `_start` symbol isn't resolved yet. Let's return to the verbose output of `gcc` and look at the parameters of `collect2`. The most important thing that we may see is that our program is linked not only with the standard library, but also with some object files. The first object file is: `/lib64/crt1.o`. And if we look inside this object file with `objdump`, we will see the `_start` symbol:
|
||||
Ok, the compiler does not complain about undefined reference of standard library functions anymore as we linked our program with `/usr/lib64/libc.so.6`, but the `_start` symbol isn't resolved yet. Let's return to the verbose output of `gcc` and look at the parameters of `collect2`. The most important thing that we may see is that our program is linked not only with the standard library, but also with some object files. The first object file is: `/lib64/crt1.o`. And if we look inside this object file with `objdump`, we will see the `_start` symbol:
|
||||
|
||||
```
|
||||
$ objdump -d /lib64/crt1.o
|
||||
$ objdump -d /lib64/crt1.o
|
||||
|
||||
/lib64/crt1.o: file format elf64-x86-64
|
||||
|
||||
@ -239,7 +239,7 @@ Disassembly of section .text:
|
||||
16: 48 c7 c1 00 00 00 00 mov $0x0,%rcx
|
||||
1d: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
|
||||
24: e8 00 00 00 00 callq 29 <_start+0x29>
|
||||
29: f4 hlt
|
||||
29: f4 hlt
|
||||
```
|
||||
|
||||
As `crt1.o` is a shared object file, we see only stubs here instead of real calls. Let's look at the source code of the `_start` function. As this function is architecture specific, implementation for `_start` will be located in the [sysdeps/x86_64/start.S](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/start.S;h=f1b961f5ba2d6a1ebffee0005f43123c4352fbf4;hb=HEAD) assembly file.
|
||||
@ -285,11 +285,11 @@ We can get all the arguments we need for `__libc_start_main` function from the s
|
||||
```
|
||||
+-----------------+
|
||||
| NULL |
|
||||
+-----------------+
|
||||
+-----------------+
|
||||
| ... |
|
||||
| envp |
|
||||
| ... |
|
||||
+-----------------+
|
||||
+-----------------+
|
||||
| NULL |
|
||||
+------------------
|
||||
| ... |
|
||||
@ -297,7 +297,7 @@ We can get all the arguments we need for `__libc_start_main` function from the s
|
||||
| ... |
|
||||
+------------------
|
||||
| argc | <- rsp
|
||||
+-----------------+
|
||||
+-----------------+
|
||||
```
|
||||
|
||||
After we cleared `ebp` register and saved the address of the termination function in the `r9` register, we pop an element from the stack to the `rsi` register, so after this `rsp` will point to the `argv` array and `rsi` will contain count of command line arguments passed to the program:
|
||||
@ -305,11 +305,11 @@ After we cleared `ebp` register and saved the address of the termination functio
|
||||
```
|
||||
+-----------------+
|
||||
| NULL |
|
||||
+-----------------+
|
||||
+-----------------+
|
||||
| ... |
|
||||
| envp |
|
||||
| ... |
|
||||
+-----------------+
|
||||
+-----------------+
|
||||
| NULL |
|
||||
+------------------
|
||||
| ... |
|
||||
@ -337,7 +337,7 @@ mov $__libc_csu_init, %RCX_LP
|
||||
mov $main, %RDI_LP
|
||||
```
|
||||
|
||||
After stack aligning we push the address of the stack, move the addresses of contstructor and destructor to the `r8` and `rcx` registers and address of the `main` symbol to the `rdi`. From this moment we can call the `__libc_start_main` function from the [csu/libc-start.c](https://sourceware.org/git/?p=glibc.git;a=blob;f=csu/libc-start.c;h=0fb98f1606bab475ab5ba2d0fe08c64f83cce9df;hb=HEAD).
|
||||
After stack aligning we push the address of the stack, move the addresses of constructor and destructor to the `r8` and `rcx` registers and address of the `main` symbol to the `rdi`. From this moment we can call the `__libc_start_main` function from the [csu/libc-start.c](https://sourceware.org/git/?p=glibc.git;a=blob;f=csu/libc-start.c;h=0fb98f1606bab475ab5ba2d0fe08c64f83cce9df;hb=HEAD).
|
||||
|
||||
Before we look at the `__libc_start_main` function, let's add the `/lib64/crt1.o` and try to compile our program again:
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user