Things like error messages (e.g in the io pkg) are actually allocated
when init() is executed. Unless we trigger a call to init(), values like
this will be nil causing various problems when we try to use functions
from the stdlib.
According to the ELF runtime handling of TLS document, the x86-64 arch
uses the same TLS handling variant (GNU) as the IA-32 ABI with the
exception that pointers are 8-byte wide and that the gs register is
swapped with fs. fs:0x0 points to the TCB; TLS variables are located
before it and are accessed using negative offsets from the TCB pointer.
In the Go case the G struct is accessed at fs:-0x8.
For more detauls see: https://www.akkadia.org/drepper/tls.pdf
By setting up pwd as a Go workspace, we can trim import paths from
something like "github.com/achilleasa/gopher-os/kernel" to just
"kernel".
These changes make forking easier and also allows us to move the code to
a different git hosting provider without having to rewrite the imports.
The rt0 code implements a dedicated function for initializing the Go runtime
structures. Instead of reserving space for a dummy g struct, the rt0
code now uses the g0 and m0 symbols defined by the runtime package. In
addition to setting up g0, the rt0 also sets up the m0 struct and links
it to g0.
Setting up m0 is a requirement for properly bootstapping the
malloc-related code in the following commits
The Makefile contains rules for invoking the offsets tool to generate
the offset definitions for members of the g, m and stack structs. The
definitions are stored in BUILD_DIR and BUILD_DIR is passed as an
include target to nasm.
The offsets tool is essentially a wrapper around "go build -a -n". It
creates a temporary folder with a dummy go file and runs the above
command using the target OS/ARCH for the kernel and captures the output.
The use of the "-a" flag forces go build to generate a build script for
rebuilding all packages including the runtime ones. As a by-product of
building the runtime package, the compiler emits the "go_asm.h" file
that contains (among other things) the offsets for each element of the
g, m and stack structures (see src/runtime/runtime2.go).
These offsets are used in Go assembly files instead of hardcoded
offsets. For example the following snippet accesses the pointer to m in
the g struct address stored at register CX:
MOVQ TLS, CX
MOVQ g_m(CX), BX
The offsets tool modifies the captured output from the go build command
so it only includes the steps up to building the runtime package,
executes the build script and post-processes the generated go_asm.h file
to retain the entries relevant to g, m and stack and then formats them
so they are compatible with nasm definitions (name equ value).
Depending on the value of the "-out" option, the tool outputs the
generated definitions either to STDOUT (default value for -out) or to a
file.
The generated DWARF information contains absolute file paths for the
source files which causes issues when debugging on OSX as GDB cannot
lookup the source files.
Summary of changes:
- when building the gdb target, the source is built with optimizations
and inlining disabled (-N -l)
- source Go gdb helpers when running the gdb target
- set split layout (asm + code)
All calls (but one) to kernel.Panic have been replaced by calls to
panic. A call to kernel.Panic is still required to prevent the compiler
from treating kernel.Panic as dead code and eliminating it.
The rt0_64 code reserves space for _rt0_redirect_table using the output
from the redirect tool's "count" command as a hint to the size of the
table. The table itself is located in the .goredirectstbl section which
the linker moves to a dedicated section in the final ELF image.
When the kernel boots, the _rt0_install_redirect_trampolines function
iterates the _rt0_redirect_table entries (populated as a post-link step)
and overwrite the original function code with a trampoline that
redirects control to the destination function.
The trampoline is implemented as a 14-byte instruction that exploits
rip-relative addressing to ensure that no registers are made dirty. The
actual trampoline code looks like this:
jmp [rip+0] ; 6-bytes
dq abs_address_to_jump_to ; 8-bytes
The _rt0_install_redirect_trampolines function sets up the abs_address
to "dst" for each (src, dst) tuple and then copies the trampoline to
"src". After the trampoline is installed, any calls to "src" will be
transparently redirected to "dst". This hack (modifying code in the
.text section) is only possible because the code runs in supervisor mode
before memory protection is enabled.
The tool scans all go sources (excluding tests) in the "kernel" package
and its subpackages looking for functions with a "go:redirect-from
symbol_name" comment. The go:redirect-from directive implies that a
function serves as a redirect target for s symbol name. For example,
the following block:
//go:redirect-from runtime.gopanic
func foo(_ interface{}){
...
}
specifies that calls to "runtime.gopanic" should be redirected to "foo".
The tool provides two commands:
- count: prints the count of redirections
- populate-table: resolve redirect symbols and populate the
_rt0_rediret_table entries in the kernel image.
As the final virtual addresses for the symbols are only known after
linking, populating this table is a 2-step process. At first, the
"count" command is used to allocate enough space for 2 x NUM_REDIRECTS
pointers. The table itself is placed with the help of the linker script
in a separate section making it easy to find its offset in the ELF
image.
After the kernel is linked, the "populate-table" command use the
debug/elf package to scan the image file and resolve the addresses for
the src and dst redirection symbols. The tool will then open the image
file in RW mode, seek to the location of the table and write the symbol
addresses for each (src, dst) tuple.
This vmm package exports ReservedZeroedFrame which can be used to setup
a lazy physical page allocation scheme. This is implemented by mapping
ReservedZeroedFrame to each page in a virtual memory region using the
following flag combination: FlagPresent | FlagCopyOnWrite.
This has the effect that all reads from the virtual address region
target the contents of ReservedZeroedFrame (always returning zero). On
the other hand, writes to the virtual address region trigger a page
fault which is resolved as follows:
- a new physical frame is allocated and the contents of ReservedZeroedFrame
are copied to it (effectively clearing the new frame).
- the page entry for the virtual address that caused the fault is
updated to point to the new frame and its flags are changed to:
FlagPresent | FlagRW
- execution control is returned back to the code that caused the fault
Page faults occurring on RO pages with the CopyOnWrite flag set will be
handled by the page handler as follows:
- allocate new frame
- establish temporary mapping for new frame
- copy original page to new frame
- update entry for the page where the fault occurred:
- set physical frame address to the allocated frame
- clear CoW flag and set Present, RW flags
- return from the fault handler to resume execution at the instruction
that caused the fault
Any other page faults will still cause a kernel panic
