| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
+ Anything extern is right out as LLVM doesn't produce correct code for
them. Maybe if I added some extra attributes but I'm skeptical.
Replaced with static variables and getters/setters.
+ Inline ASM is apparently a bit buggy, so use an assembly stub when jumping to init.
+ Minimize work done in main() to minimize chance of LLVM doing something silly.
Still not 100% certain that I shouldn't just write the main() as an assembly stub
in arch/riscv64 to be absolutely sure everything works as intended.
+ Make .kernel.start section SHF_ALLOC, otherwise lld complains about
pc-relative addressing
Probably some other stuff as well that I'm forgetting right now. But at least with
LLVM14 LTO seems to work, which is pretty cool?
|
|
+ No real point having multiple different levels of assertions, just say
you assert something and be done with it
|
|
+ Had some minor issues with a wraparound of size_t that effectively
meant that some regions were allocated twice. Also, booting should be
a bit more reliable now, turned out that the previous iteration of the
booting was just accidentally working due to the kernel being placed
'close enough' in RAM to where it was linked to. Fixed by allocating a
vmem of O1 that maps the kernel to a 2MiB boundary at boot, pretty
nifty.
|
|
+ dbg_fdt() is apparently broken, possibly due to UB or something, but
it causes some issues with optimizations enabled. Remove it
temporarily
|
|
+ Fairly considerable speedup, as we don't have to look up the rpc pte
every time separately, instead cacheing them. Adds an architecture
specific limitation to total rpc stack size, though.
|
|
+ Only occur with my version of riscv64-linux-gnu-gcc. Funny, that.
|
|
|
