docs: documented stack-tracing

This commit is contained in:
antifallobst 2023-03-01 22:21:28 +01:00
parent 7a0e3632e7
commit 578c9baf02
1 changed files with 35 additions and 7 deletions

View File

@ -55,22 +55,27 @@ When a fatal / not recoverable error occurs, the kernel panics. It logs panic in
Such a panic log can look like the following one:
```
[ Error ] !=====[ KERNEL PANIC ]=====!
Interrupt ID: 0x0E
Error Code: 0b00000000000000000000000000000010
Error Message: Page Fault
Error Message: Division Error
Interrupt ID: 0x00
Error Code: 0b00000000000000000000000000000000
Paging Info:
Page Map: 0x000000000FB0A000
Page Map: 0x000000000FAE9000
CPU Flags:
Parity
Sign
Interrupt Enable
CPU Registers:
RIP: 0xFFFFFFFF8000027A RAX: 0x0000100000079838 RBX: 0x0000000000000000
RCX: 0xFFFFFFFFFFFFFFD8 RDX: 0x0000000000000000 RSI: 0x0000000000000000
RDI: 0x0000100000079838 RBP: 0xFFFF80000FB1AF10 RSP: 0xFFFF80000FB1AEF0
RIP: 0xFFFFFFFF80002745 RAX: 0x0000000000000001 RBX: 0x0000000000000000
RCX: 0x0000000000000000 RDX: 0x0000000000000000 RSI: 0x000000000001F980
RDI: 0x00001000005DF7A0 RBP: 0xFFFF80000FAF9F40 RSP: 0xFFFF80000FAF9F30
Call Stack:
0xFFFFFFFF80000000+033F -> _start
0xFFFFFFFF8000274D+0078 -> kmain
0xFFFFFFFF80002732+0013 -> test
[ Warning ] !=====[ HALTING SYSTEM ]=====!
```
but what does it say?
@ -98,6 +103,10 @@ If this block doesn't appear, there are no bits set.
This is probably the most interesting block, because you get very detailed information out of here,
if you know what each of these registers does in the cpu.
`Call Stack` lists the current function call chain, starting from the least recent call.
The big hex number is the base of the function and the small hex number is the offset, where the next function was called.
After the `->` follows the name of the function.
### Panic without interrupt
If the panic wasn't caused by an interrupt, it has no cpu_state, and because of that it has no detailed info about the execution state.
In this rare case, you will get the following message:
@ -367,6 +376,13 @@ An array of strings matching `elf_object_type_E`.
#### `g_elf_instruction_set_strings` - global variable
An array of strings matching `elf_instruction_set_E`.
#### `elf_init_kernel_exec(boot_info)` - function (void) [Will be replaced in near future]
Loads the kernel elf into `g_kernel_executable`.
#### `g_kernel_executable` - global variable [Will be replaced in near future]
Holds the parsed kernel executable.
This will be removed, when processes are implemented, because then this can be accessed via the kernel process control struct.
### elf/section.h
#### `elf_section_type_E` - enum
@ -925,6 +941,15 @@ This reads the current page map set by the kernel and writes it to `g_kernel_pag
#### `g_kernel_page_map` - global variable
The kernels page map. This page map is provided by the bootloader and read from `cr3` at `paging_init`.
### stack.h
#### `stack_dump_call_info(rip, symbol)` - function (void)
Logs information about a call.
Give this function the **_rip_** of the call and the related **_symbol_**, to make it happy.
#### `stack_trace_call_stack(rbp)` - function (void)
Analyses the stack and recursively dumps information about all calls until it hits a call to `_start`.
## platform
### cpu.h
@ -1377,3 +1402,6 @@ This string will be written into **_string_**.
| name | string_t | The name of the symbol (e.g. the name of the kernels entry symbol would be `_start` |
| type | symbol_type_E | The symbols type (elf types like `File` are of type `Unknown`) |
| address | uint64_t | The symbols address |
#### `symbol_resolve_function_from_rip(symbols, num_symbols, rip);` - function (symbol_T*)
Give it a list of **_symbols_** and an instruction pointer (**_rip_**) and it will return the function, where **_rip_** lays in.