OBOS (not vibecoded) | Operating System Development | Page 6

flint idol Apr 27, 2024, 9:32 PM

#

I'd just set it to some arbitrary value

real pecan Apr 27, 2024, 9:32 PM

#

because what u do is cpu mmu emulation

#

its not productive

flint idol Apr 28, 2024, 1:14 AM

#

After fighting with KASAN to not crash or be slow af

#

I finally get a violation

#

ASAN Violation at ffffffff8001a276 while trying to read 8 bytes from 0x0000000000000000.```

#

While initializing the scheduler

#

But of course that's in the VMM

flint idol Apr 28, 2024, 1:16 AM

#

flint idol After fighting with KASAN to not crash or be slow af

I just realized that I've been doing something extremely stupid

#

I've been checking if the address that's trying to be accessed was allocated by the kernel allocator

#

then if it was

#

it would check if the address falls into the shadow space after the node

#

It could've easily been a memcmp to check if the address is poisoned (all n bytes are set to 0xA5)

#

Upon doing that

#

I triple fault

#

Bug with memcmp?

#

As you can see my kernel is very stable

#

oops:

mov al, dil
mov rcx, rdx
repe scasb
sete al```

#

spot the mistake?

#

for reference this is the signature:

#

bool memcmp(void*, uint8_t against, size_t count)

sharp pike Apr 28, 2024, 1:23 AM

#

that's not the right signature

#

fix that

flint idol Apr 28, 2024, 1:23 AM

#

No

#

That's my own special memcmp

#

I have another for comparing memory blocks

sharp pike Apr 28, 2024, 1:24 AM

#

if the symbol is called memcmp then you should make it work like the standard memcmp

#

because the compiler expects that

flint idol Apr 28, 2024, 1:24 AM

#

The symbol is mangled

sharp pike Apr 28, 2024, 1:24 AM

#

ah

#

then nvm

flint idol Apr 28, 2024, 1:24 AM

#

I should probably fix that though

#

I only have mangled versions of memcmp, memcpy, and memset

flint idol Apr 28, 2024, 1:56 AM

#

Well some vmm node is getting zeroed or is never getting initialized

#

Because it is zeroed I can't even find out what address it's supposed to point to

#

That is because the VMM is reallocating pages again

#

Whoopsie...

#

It was because of the interdependency between the allocator and VMM

#

The VMM was requesting a page node

#

But the allocator needed more room

#

and the conditions were just right in this case for the VMM to choose the same base address

#

for the allocator

#

The fix to this is

#

idk

#

I can only think of temporarily adding the node passed to AppendPageNode

#

So it doesn't get reallocated

#

and then removing it once the node on the heap is added

#

which is pretty hacky imo

#

The problem is deeper

#

It occurs before the node can be appended in the vmm's allocate function

#

ie. in it's initialization

#

I described how my VMM finds addresses somewhere in #1230349543623757845

#

So the only solution is to rather change that

#

or remove the interdependency

flint idol Apr 28, 2024, 2:27 AM

#

flint idol So the only solution is to rather change that

I could separate the allocator's regions and other kernel regions

#

So that this becomes impossible to happen

#

I'll just reserve a shit ton of memory for the allocator

#

and commit parts of it whenever the allocator needs to grow

#

Anyway sounds like a problem for tomorrow

flint idol Apr 28, 2024, 10:19 AM

#

I thought of another idea to fix the bug. That is to remove the interdependency entirely. One way I thought of doing that is using the hhdm along with pages from the PMM. Although since continuous physical pages are inefficient to get, this will only be done for the vmm's allocator.

#

The normal kernel allocator should be able to keep using the vmm to allocate new regions

flint idol Apr 28, 2024, 10:48 AM

#

flint idol I thought of another idea to fix the bug. That is to remove the interdependency ...

Although this has the disadvantage that guard pages cannot be added to pages allocated in the HHDM, so memory being written past the region's limit will corrupt other blocks of physical memory

#

That'd be a fun bug to track down

flint idol Apr 28, 2024, 11:23 AM

#

I just found a very dumb memory corruption bug

#

Well not very dumb

#

More like an oversight

#

I was initially using the regular new/delete operator pair for allocating/freeing page nodes and page descriptors

#

When I gave the VMM its own allocator, I just overloaded the new operator for page_node and page_descriptor

#

But I didn't overload the delete operator

#

Causing all VMM frees to go through the general kernel allocator (not good)

#

Sometimes I'm genuinely surprised how bugs like this go untriggered for so long

#

Ok it works now

#

ie. boots with no problem

#

Just a "bit" slower

#

I should fix my UB that UBSan detects

#

Then I can fulfill [this](#1217009725711847465 message)

vernal chasm Apr 28, 2024, 11:40 AM

#

flint idol I was initially using the regular `new`/`delete` operator pair for allocating/fr...

O_O

#

Should've used C :>

flint idol Apr 28, 2024, 11:41 AM

#

I don't see how it's the language's fault

#

In this case

vernal chasm Apr 28, 2024, 11:41 AM

#

You wouldn't use new/delete

#

kekw

flint idol Apr 28, 2024, 11:41 AM

#

Then I would use kmalloc/kfree

#

Literally the same thing except I pass the size

vernal chasm Apr 28, 2024, 11:42 AM

#

flint idol Then I would use `kmalloc`/`kfree`

Which is more verbose as to which allocator you're using

flint idol Apr 28, 2024, 11:42 AM

#

No it wouldn't if I went with the same design that my kernel uses

#

actually nvm

lean glen Apr 28, 2024, 11:43 AM

#

You can literally pass an allocator to new

#

If you want

flint idol Apr 28, 2024, 12:07 PM

#

I enabled KASAN in uACPI's static library and there is coincidentally a table which contains KASAN's value that it uses for poisoning

#

Reporting a KASAN violation

#

Seems like I need to use a more random value

flint idol Apr 28, 2024, 12:30 PM

#

flint idol Seems like I need to use a more random value

I decided to instead attempt further verifying if the address is actually poisoned and doing that

#

the value 0xA5 seems to come up in ACPI Tables quite often

#

I just found a USB stick with a very, very early revision of my first kernel

#

In it's protected mode, vga text mode glory

#

Time to see what it does

#

"Hello, world!"
Triple fault

#

I also found another

#

That used some crappy acpi shutdown function on the osdev wiki

vernal chasm Apr 28, 2024, 12:40 PM

#

flint idol I enabled KASAN in uACPI's static library and there is coincidentally a table wh...

That's kinda oof

vernal chasm Apr 28, 2024, 12:40 PM

#

flint idol "Hello, world!" Triple fault

Now that's how you osdev

#

kekw

flint idol Apr 28, 2024, 12:41 PM

#

I just found a usb stick with my 2nd kernel

#

Time to see what it does

#

"Entering rescue mode"
"grub rescue> "

#

KEKW

flint idol Apr 28, 2024, 12:45 PM

#

vernal chasm Now that's how you osdev

A lot more reliable then what modern kernels call "memory mangement" or "scheduling"

#

KASAN+my kernel on my laptop = slow af

#

Until it finally reaches the test driver

#

where it finishes

#

and asan reports an asan violation

#

the stack trace is pretty goofy

#

the first stack trace entry is asan_report

#

then panicVariadic

#

then reportKASANViolation

#

Letting the kernel panic through the debugger

#

Reports stack corruption and not kasan violation

#

I think I should poison the stack through KASAN

#

That might catch uninitialized variable access

#

Instead it:

Attempt to call LowerIRQL() with the irql 15, which is greater than the current IRQL, 0.```

#

That doesn't happen second reboot

#

or after fixing a bug with a use of uninitialized variable

flint idol Apr 28, 2024, 2:17 PM

#

I have found a scheduler bug

#

Where if the kernel main thread exits

#

ie. it gets terminated

#

The scheduler will find a way to switch to the part of KernelArchInit that checks for the watchdog timer

#

Of course, because why not, the code gets run as the BSP's idle task

flint idol Apr 28, 2024, 2:41 PM

#

Attempt to call LowerIRQL() with the irql 15, which is greater than the current IRQL, 15.```

#

thinkong

flint idol Apr 28, 2024, 3:12 PM

#

Solution: Remove stack poisoning

#

Anyway I may or may not have 22 outgoing commits

#

But this time I tried to only keep a couple changes per commit

#

Instead of one fat commit for changes to everywhere

#

Between current commit and master:

54 files changed, 1252 insertions(+), 341 deletions(-)```

flint idol Apr 28, 2024, 3:49 PM

#

I've merged that branch

#

and also merged the vfs branch

#

then I made it again

#

so it can have the bug fixes

#

and other changes

#

Anyway, what was I doing before this

#

Ah yes VFS

#

I guess I'll have some struct

#

that stores an opened file's context

#

ie. the offset

#

how it was opened

#

etc.

#

Then I'll have some member functions

#

that initialize it (open a file)

#

read from the file

#

write to it

#

close it

#

whatever else a file descriptor does

flint idol Apr 28, 2024, 8:33 PM

#

I have found a scheduler bug

#

I just don't know why it happens

#

Nor do I want to look into why it happens

#

But it doesn't happen all the time

#

Time to use UBSan I guess

ashen goblet Apr 28, 2024, 8:49 PM

#

what does it do

flint idol Apr 28, 2024, 8:49 PM

#

what the bug?

#

causes a GPF

ashen goblet Apr 28, 2024, 8:49 PM

#

interesting

flint idol Apr 28, 2024, 8:49 PM

#

(of course as I turn on UBSan the bug disappears)

#

I'm sure it'll come back

#

it just happened

#

with no UBSan violations...

#

Time to turn on KASAN

#

With KASAN, I get stack corruption

#

i.e., it causes the stack corruption

#

It reports the stack corruption in scheduler::yield

#

All I wanted was an implementation of KASAN, is that so hard to ask for?

#

Why does it have to do all this

flint idol Apr 28, 2024, 9:11 PM

#

Very goofy stack trace:

Stack trace:
        0xffffffff800344eb: _ZN4obos6logger9panicImplEPvbPKcP13__va_list_tag+378
        0xffffffff8003430b: _ZN4obos6logger20reportKASANViolationEPKcz+0
        0xffffffff800342d9: _ZN4obos6logger13panicVariadicEPvPKcP13__va_list_tag+0
        0xffffffff80050b14: _ZN4obos3vfs11string_viewC1EPKc+0
        0xffffffff8004f296: _ZN4obos9scheduler5yieldEv+370```

#

let's see what it becomes on a reboot

#

it becomes nothing

#

These bugs are making me want to rewrite my kernel, although I must resist

flint idol Apr 28, 2024, 9:41 PM

#

The stack seems to be getting fucked by my scheduler

#

Somehow

#

Time for more debugging on how

#

Specifically, the yield() function

limber wave Apr 28, 2024, 9:42 PM

#

flint idol Time for more debugging on how

this guy made more debugging than those who tested GDB

flint idol Apr 28, 2024, 9:42 PM

#

My kernel should be used as a test case for GDB

#

That'd probably not even be that bad of a way of testing it

#

Considering how much bugs I produce

real pecan Apr 28, 2024, 9:43 PM

#

Lol

flint idol Apr 28, 2024, 9:45 PM

#

maybe adding a cli in the YieldThread function (which saves thread context and calls the scheduler) will help

#

Well that certainly does something

#

Whether that thing is a good thing or not, idk

#

I'll wait to see if KASAN reports anything or if anything shits itself

#

Well

#

nothing shat itself

#

but that's probably a lucky run

#

hmmm

#

another reboot worked

#

I'll try again...

#

three reboots and not one fails with magical memory corruption

#

I'll rebuild

#

then run qemu

#

and see what happens

#

It works

#

Time to consider this bug fixed until not fixed

#

KASAN significantly slows down the kernel

real pecan Apr 28, 2024, 9:52 PM

#

Do u even understand why that was a bug

flint idol Apr 28, 2024, 9:52 PM

#

So I'll disable that until I need it

#

Nope

real pecan Apr 28, 2024, 9:52 PM

#

Perhaps u just made the bug more unlikely to trigger

flint idol Apr 28, 2024, 9:53 PM

#

Well if a cli made it not get triggered over 4 reboots

#

that probably means YieldThread got preempted by an interrupt

#

(similar behaviour also happens when I try to get my IRQs preemptible)

#

I do use ISTs for some interrupts in my kernel

#

Which uses the CPU temp stack

#

oh dear

#

so does the scheduler

#

maybe that was my previous kernel and I'm misremembering

#

it was my previous kernel that did that

#

oops

#

double faults use ist 2

#

but that's never initialized

#

No IRQ uses IST stacks

#

only certain exceptions

#

I'm going to remove the cli

#

and disable ISTs

#

for all interrupts

#

and I'll see what happens

#

triple fault

#

oh yeah

#

I remember now

#

I need to map all stacks as no demand page

#

after fixing that, everything goes to shit

#

ISTs aren't the root cause

#

Maybe ISRs somehow leave the stack in a goofy state

#

Doubt it though

#

Well I would've noticed that a long time ago

#

I don't know why this bug happens

#

all I know is disabling interrupts in YieldThread "fixes" it

real pecan Apr 28, 2024, 10:06 PM

#

Shouldn't matter

flint idol Apr 28, 2024, 10:06 PM

#

Maybe it has something to do with KASAN being disabled in only some functions the scheduler depends on

#

idk how that would affect anything though

flint idol Apr 28, 2024, 10:35 PM

#

I got the VFS's look for index node function working

#

I just need to vigorlessly test it

#

(with three available nodes for it to test)

#

I'll also do goofy stuff with the path to test if parsing the path works

#

like putting many slashes beside each other for no reason

#

Parsing the path seems to work

#

I'll try paths relative to the root passed to LookForIndexNode

#

see what that does

#

doesn't work

#

It's a problem with parsing the path

#

Fixed it

#

I'll also try adding ../ to the path and see if that gets messed up

#

oops

#

infinite recursion

#

I fixed it

#

I'll try adding ./ to see if that works

#

page fault

flint idol Apr 28, 2024, 11:09 PM

#

ok I fixed it

#

I'll try to look off of a node

#

that works

flint idol Apr 29, 2024, 1:24 AM

#

I saw a gdb option for instrumenting functions, and I thought it would be nice if I could implement it.

#

To see what functions take the longest

#

which get called the most

#

etc.

#

It's only two functions I need to implement

#

and they can technically be pretty simple

flint idol Apr 29, 2024, 2:09 AM

#

The downside is that everything related to the VMM and allocator now needs to be marked as no_instrument_function or everything will go to shit because of recursion (the function for recording function calls may or may not depend on the allocator)

#

Which means not the allocator nor the VMM can be instrumented (at least not in kernel mode)

#

Although anything else can be

flint idol Apr 29, 2024, 2:10 AM

#

flint idol The downside is that everything related to the VMM and allocator now needs to be...

and I have to do this for ANY dependency of them

#

Even so much as an exception handler

#

or the IRQL functions

#

or spin lock (although tbf that shouldn't be instrumented anyway)

#

I feel bad for anyone who wanted to port OBOS (me in the future)

#

There will be so much forgotten quirks

#

Like this

#

That will pop out of no where

#

Even one liner functions in the VMM have to be marked

#

as no instrument

#

because there is the slight off-chance that infinite recursion happens

#

Now luckily for me the VMM nor the allocator really depend on anything else in the kernel

#

Ok I'm done a very barebones implementation

#

Time to see whether it shits itself (it will)

#

You know what this is too unstable

flint idol Apr 29, 2024, 1:25 PM

#

I might rewrite the kernel (again)

#

note how "might" is emphasized

#

The reasons, well, look above this message

#

Mainly kernel instability

#

But that can always be fixed, my previous kernel at one point had similar problems

#

Except none of which were with the allocator

#

Mainly scheduler instability

flint idol Apr 29, 2024, 1:28 PM

#

flint idol Except none of which were with the allocator

Actually there were some

#

The allocator would be ported if I rewrite

unkempt pawn Apr 29, 2024, 1:46 PM

#

Oh man how many rewrites have been done already lol

flint idol Apr 29, 2024, 1:50 PM

#

This is the 4th revision

#

So the next would be the 5th

flint idol Apr 29, 2024, 2:17 PM

#

#

Me programming OBOS

devout niche Apr 29, 2024, 2:57 PM

#

flint idol

what is it that you're worried you've miscoded/misarchitected?

flint idol Apr 29, 2024, 3:46 PM

#

Well for one I messed up IRQs a bit

#

I wanted them to be preemptible

#

It's not really too late for that

#

It's just a lot of debugging because when I tried the kernel shat itself

#

The kernel, at least in the early stages of boot, is really fragile

flint idol Apr 29, 2024, 4:06 PM

#

I shall rewrite the kernel (starting in a couple hours)

#

I'll merge VFS with master then rename master to some old_code

#

This time, I'll rewrite in C

limber wave Apr 29, 2024, 4:18 PM

#

C? What language werr you using before?

flint idol Apr 29, 2024, 4:18 PM

#

C++

limber wave Apr 29, 2024, 4:19 PM

#

I think you probably were not using C++ features anyways, but if that's the case the rewrite will be much easier anyways

ashen goblet Apr 29, 2024, 4:27 PM

#

flint idol I shall rewrite the kernel (starting in a couple hours)

No way 🤣

#

Can I place a bet on how many rewrites until you stop doing osdev

limber wave Apr 29, 2024, 4:29 PM

#

would not it be better to take your time and slowly build up working code instead of slowly building up bugs? That's what you say, but also what you should really do

#

you will just waste your time otherwise

flint idol Apr 29, 2024, 4:29 PM

#

Yeah that's what I'll do this time

#

I'm going to try and get KASAN and UBSAN asap

#

to prevent those bugs

limber wave Apr 29, 2024, 4:30 PM

#

flint idol Yeah that's what I'll do this time

heavily test each part, trying different edge cases, analyzing the values and so on

flint idol Apr 29, 2024, 4:30 PM

#

I'll test everything

#

vigorously

#

This rewrite might take longer to get to around the same state as this kernel

#

But at least it won't be buggy af

ashen goblet Apr 29, 2024, 4:31 PM

#

first uncursed version of obos incoming?

flint idol Apr 29, 2024, 4:31 PM

#

the third kernel wasn't cursed

limber wave Apr 29, 2024, 4:31 PM

#

ashen goblet first uncursed version of obos incoming?

place your bet, come on!

limber wave Apr 29, 2024, 4:31 PM

#

flint idol the third kernel wasn't cursed

it was just a bit devil

#

nothing to worry about (I was not even here)

flint idol Apr 29, 2024, 4:32 PM

#

No it was fine and relatively stable

#

It was able to get to a point where I could port a libc

#

until someone (hyenasky) saw my VMM and made me want to rewrite

#

I also decided some parts were designed poorly

#

He was banned in this server

limber wave Apr 29, 2024, 4:32 PM

#

you could use the best of all the rewrites

flint idol Apr 29, 2024, 4:32 PM

#

But you can find him elsewhere

limber wave Apr 29, 2024, 4:33 PM

#

flint idol He was banned in this server

yeah I know

#

do you usually test your code in a controlled environment?

flint idol Apr 29, 2024, 4:33 PM

#

Nope

limber wave Apr 29, 2024, 4:33 PM

#

why?

flint idol Apr 29, 2024, 4:34 PM

#

Too tempting to just go on and use the feature

limber wave Apr 29, 2024, 4:34 PM

#

flint idol Too tempting to just go on and use the feature

is that a pun which my english does not understand?

flint idol Apr 29, 2024, 4:34 PM

#

nope

limber wave Apr 29, 2024, 4:34 PM

#

which feature?

flint idol Apr 29, 2024, 4:34 PM

#

most

#

scheduler was completely untested when I was done with it

limber wave Apr 29, 2024, 4:35 PM

#

and that is the root of all your problems

flint idol Apr 29, 2024, 4:35 PM

#

VMM was very lightly tested

#

which is why the allocator bug came up

#

It was a bug in vmm::Free which could've been fixed if I tested

limber wave Apr 29, 2024, 4:36 PM

#

flint idol VMM was very lightly tested

well hyenasky has a very advanced os afaik so it is not a surprise that your untested code might have had some poor design choices

#

in contrast

flint idol Apr 29, 2024, 4:38 PM

#

If anyone needs to test their debugger, you can use the fourth kernel

limber wave Apr 29, 2024, 4:38 PM

#

but you couls have continued from there, or you can roll back now

#

to a certain degree

flint idol Apr 29, 2024, 4:39 PM

#

btw I still haven't started the rewrite

#

I'm at school

#

I can't just start a rewrite in the middle of class

limber wave Apr 29, 2024, 4:39 PM

#

that means you can still think on what is the best way of doing it before heading in

limber wave Apr 29, 2024, 4:39 PM

#

flint idol I can't just start a rewrite in the middle of class

yeah obv

flint idol Apr 29, 2024, 4:40 PM

#

oh btw for this rewrite I'm using the hyper bootloader

limber wave Apr 29, 2024, 4:41 PM

#

flint idol oh btw for this rewrite I'm using the hyper bootloader

any particular reason?

#

(never heard of it)

flint idol Apr 29, 2024, 4:41 PM

#

nah

#

I just want to

#

Hyper is @real pecan's bootloader

#

https://github.com/UltraOS/Hyper

real pecan Apr 29, 2024, 4:47 PM

#

Good luck with the rewrite

flint idol Apr 29, 2024, 4:48 PM

#

ty

limber wave Apr 29, 2024, 4:48 PM

#

yes, good luck!

devout niche Apr 29, 2024, 5:11 PM

#

yes

#

best wishes

thick jolt Apr 29, 2024, 8:18 PM

#

hey guys

thick jolt Apr 29, 2024, 8:18 PM

#

real pecan Good luck with the rewrite

is he rewriting again ????

thick jolt Apr 29, 2024, 8:19 PM

#

flint idol This time, I'll rewrite in C

good

#

😎

#

C is key!

#

actually will probs be easier cause no oop!

#

😎 😎

#

man i love C

ashen goblet Apr 29, 2024, 8:22 PM

#

thick jolt actually will probs be easier cause no oop!

oop isn’t exactly harder

thick jolt Apr 29, 2024, 8:22 PM

#

ashen goblet oop isn’t exactly harder

well C++ is just idk, idk man i dont code oop ☠️

ashen goblet Apr 29, 2024, 8:22 PM

#

C++ is more than c with classes

thick jolt Apr 29, 2024, 8:23 PM

#

yea and i dont like classes

weary hound Apr 29, 2024, 8:23 PM

#

then don't use them?

thick jolt Apr 29, 2024, 8:23 PM

#

weary hound then don't use them?

yea thats why i use C 😎

weary hound Apr 29, 2024, 8:24 PM

#

waiting for you to reinvent a vtable with a struct of function pointers

#

:^)

thick jolt Apr 29, 2024, 8:24 PM

#

my brain just went 💥

empty kernel Apr 29, 2024, 8:30 PM

#

flint idol I __***might***__ rewrite the kernel (again)

How many rewrites do you think you will do before you'll be happy with OBOS.

flint idol Apr 29, 2024, 8:30 PM

#

Yes.

#

hopefully this one

#

but that's what I've said for each other kernel, so idk

#

I've almost been doing osdev for a year

#

which is le cool I guess

#

Definitely felt a lot less than a year

empty kernel Apr 29, 2024, 8:32 PM

#

Only a year? I've been doing osdev for almost 2 years, and I'm still on the same kernel.

flint idol Apr 29, 2024, 8:32 PM

#

My kernels' timeline:

#

First kernel may 2023-august 2023

#

second august 2023-october 2023

#

third october 2023-february 2024

#

fourth february 2024-(basically may) april 2024

flint idol Apr 29, 2024, 9:05 PM

#

I think this rewrite will keep some parts of the previous build system

#

Like dependency management

#

I'll spend a bit of time on that, then move onto the gdt (copying and pasting the previous kernel's gdt)

#

First though I got to make a new branch for the rewrite

empty kernel Apr 29, 2024, 9:06 PM

#

Theres no point rewriting things like the GDT, which are working well.

flint idol Apr 29, 2024, 9:07 PM

#

I know I use git branch -c to make a new branch based on another branch

#

but what do I use to make a new branch

#

ie. one with no commit history

#

I'll just search

#

git checkout --orphan

#

The github repo will be a bit goofy for a bit

#

whoops

#

I accidentally put in the old kernel's readme

#

ok the github repo is good

#

except there is nothing except for the branch for the old code

#

and master that only has markdown files and the license

empty kernel Apr 29, 2024, 9:26 PM

#

flint idol and master that only has markdown files and the license

what license do you use?

flint idol Apr 29, 2024, 9:26 PM

#

MIT

#

best license

empty kernel Apr 29, 2024, 9:38 PM

#

I used that until I came across GPLv3

flint idol Apr 29, 2024, 9:39 PM

#

boo

empty kernel Apr 29, 2024, 9:40 PM

#

I like GPLv3 because you have to state changes

flint idol Apr 29, 2024, 9:50 PM

#

hmmm should I use C23 for obos

#

gcc has support for most of it

chilly osprey Apr 29, 2024, 9:50 PM

#

use c++23

flint idol Apr 29, 2024, 9:50 PM

#

bruh

#

I'm using C

#

oh wait

#

Well C23 is quite new

#

obvious solution is use ANSI C

#

I'll use C17

#

It's not so new that modern compilers don't have some features

#

but not that old either

limber wave Apr 29, 2024, 10:02 PM

#

C23 has constexpr so it’s obviously based

flint idol Apr 29, 2024, 10:02 PM

#

yeah but compiler support for it is unstable

limber wave Apr 29, 2024, 10:05 PM

#

flint idol I'll use C17

c17 is basically c11

flint idol Apr 29, 2024, 10:05 PM

#

yeah I know

ashen goblet Apr 29, 2024, 10:36 PM

#

limber wave C23 has constexpr so it’s obviously based

constexpr in c feels wrong

weary hound Apr 29, 2024, 10:38 PM

#

constexpr in c solves the problem of const int x = 5; int foo[x]; making a VLA

#

because now you can mark it constexpr instead of just const

ashen goblet Apr 29, 2024, 10:41 PM

#

Yeah that makes sense

flint idol Apr 29, 2024, 10:43 PM

#

I got the kernel to boot into while(1);

#

This time the kernel is using c 😎

real pecan Apr 29, 2024, 10:43 PM

#

At least it's stable

flint idol Apr 29, 2024, 10:44 PM

#

lol

#

time to copy+paste the gdt

real pecan Apr 29, 2024, 10:44 PM

#

Most stable oberrow kernel

flint idol Apr 29, 2024, 10:44 PM

#

good thing I coded my gdt in asm

empty kernel Apr 29, 2024, 10:45 PM

#

For how long will it stay stable?

flint idol Apr 29, 2024, 10:45 PM

#

for the previous kernel

flint idol Apr 29, 2024, 10:45 PM

#

empty kernel For how long will it stay stable?

around 1 minute

real pecan Apr 29, 2024, 10:45 PM

#

empty kernel For how long will it stay stable?

Until scheduler

flint idol Apr 29, 2024, 10:45 PM

#

when I port my GDT

empty kernel Apr 29, 2024, 10:46 PM

#

What order are you planning on making things in?

flint idol Apr 29, 2024, 10:46 PM

#

gdt

#

idt

#

IRQs and IRQL

#

scheduler

#

VMM

#

also with vmm comes page cache

#

GDT is working

empty kernel Apr 29, 2024, 10:47 PM

#

Wouldnt it make more sense to do vmm before scheduler? Also, you forgot the PMM

flint idol Apr 29, 2024, 10:47 PM

#

oh yeah

flint idol Apr 29, 2024, 10:48 PM

#

empty kernel Wouldnt it make more sense to do vmm before scheduler? Also, you forgot the PMM

no

#

scheduler must have no dependencies

flint idol Apr 29, 2024, 10:48 PM

#

flint idol VMM

PMM before this

flint idol Apr 29, 2024, 10:48 PM

#

flint idol scheduler must have no dependencies

Even not IRQs

#

A wise man once told me that the timer IRQ shouldn't be linked to the scheduler

#

so it makes sense to just make it so early

#

that it can't depend on anything

empty kernel Apr 29, 2024, 10:49 PM

#

What about the kernel heap?

flint idol Apr 29, 2024, 10:49 PM

#

in-between PMM and VMM

#

btw VMM != page table manager

#

a wise man told me that aswell

#

actually he told that to @vernal chasm

flint idol Apr 29, 2024, 10:50 PM

#

flint idol idt

ok IDT here I got

#

time for a lot of porting (I'm not writing this again)

#

Ok this is how symbols will be named:

Arch_* arch specific code
OBOS_* General kernel code
Mm_* VMM code
Vfs_* VFS Code
Io_* Io manager
Core_* Scheduler, IRQ code, other code in the kernel that are essential to the kernel working.
Kdbg_* Kernel debugger-related functions.
Drv_* Driver interface/loader functions.
'S' suffix to a namespace name means the symbol is declared by the arch-independent part of the kernel, but the architecture must define the symbol itself.
'H' suffix to namespace name means the symbol is a helper function.
TODO: Add more```

empty kernel Apr 29, 2024, 10:55 PM

#

What about things that are exclusive to x86_64?

flint idol Apr 29, 2024, 10:55 PM

#

Arch_

#

arch specific code

#

The others will be solely for arch-independant code

#

note that list is only for global exposed symbols

#

statically-linked ones aren't counted

#

structs will be named in snake_case

#

functions will be named in PascalCase

#

because why not

#

Finally my stack traces won't be wider than they are deep

vernal chasm Apr 29, 2024, 11:12 PM

#

flint idol actually he told that to <@272414379083825154>

wut

flint idol Apr 29, 2024, 11:51 PM

#

A wise man told you that a VMM is not a page table manager

#

#560042023638269955 message

#

Hyper is a bit too fast for my own good

#

I can't tell a triple fault from goofy control flow

real pecan Apr 30, 2024, 12:00 AM

#

lol

#

it was 5 times faster than limine for the limine barebones kernel example last time I tested

flint idol Apr 30, 2024, 12:00 AM

#

ok the int3 instruction doesn't triple fault

#

just the question is, does it work?

#

it indeed does

#

I think I'll leave the IRQ interface for after I port the allocator

#

Ok now IRQL

#

Pretty straightforward

vernal chasm Apr 30, 2024, 12:02 AM

#

flint idol A wise man told you that a VMM is not a page table manager

Ah yes

flint idol Apr 30, 2024, 12:03 AM

#

Because these commits are so straightforward I'm just directly pushing to master

#

They're not really tied to a feature

#

I think I might put all functions in a certain "namespace" (whatever the prefix to the function is) in their own directory

#

Actually no

#

only for some

#

IRQL functions are going under the OBOS "namespace"

real pecan Apr 30, 2024, 12:05 AM

#

u might want to make the namespace prefix simpler like NT

#

so its easier to type out

flint idol Apr 30, 2024, 12:06 AM

#

I'll see what NT does

real pecan Apr 30, 2024, 12:06 AM

#

Ke Rtl etc

#

or Nt

flint idol Apr 30, 2024, 12:07 AM

#

From what I see from a wikipedia page, Nt is for syscalls

real pecan Apr 30, 2024, 12:07 AM

#

no idea

flint idol Apr 30, 2024, 12:07 AM

#

Wait NT calls SSDT the "system service descriptor table"

real pecan Apr 30, 2024, 12:08 AM

#

does it tho

#

flint idol Apr 30, 2024, 12:09 AM

#

Nt or Zw are system calls declared in ntdll.dll and ntoskrnl.exe. When called from ntdll.dll in user mode, these groups are almost exactly the same; they execute an interrupt into kernel mode and call the equivalent function in ntoskrnl.exe via the SSDT. When calling the functions directly in ntoskrnl.exe (only possible in kernel mode), the Zw variants ensure kernel mode, whereas the Nt variants do not. The Zw prefix does not stand for anything
From here

#

Well I guess calls it was misleading

vernal chasm Apr 30, 2024, 12:10 AM

#

I still don't really know what Rtl or Zw means kekw

real pecan Apr 30, 2024, 12:10 AM

#

oh thats unrelated to acpi lol

#

its some nt thing

vernal chasm Apr 30, 2024, 12:10 AM

#

Ik

#

kekw

real pecan Apr 30, 2024, 12:10 AM

#

i was talking to oberrow

vernal chasm Apr 30, 2024, 12:10 AM

#

ah xD

flint idol Apr 30, 2024, 12:13 AM

#

I think a reason the old kernel was so fragile was because everything depended on everything

#

it was a big clusterfuck of dependencies

#

so changing one thing that is seemlingly unrelated to something else can cause the kernel to 💩

#

Before I get to the rest of the kernel I need a way to log

#

stuff

#

and panic

vernal chasm Apr 30, 2024, 12:16 AM

#

lmao

real pecan Apr 30, 2024, 12:16 AM

#

flint idol Before I get to the rest of the kernel I need a way to log

use nanoprintf or stbprintf

#

instead of c++ logging

vernal chasm Apr 30, 2024, 12:16 AM

#

Imagine changing how system time is computed and the pmm dies

flint idol Apr 30, 2024, 12:17 AM

#

probably could've happened lol

flint idol Apr 30, 2024, 12:17 AM

#

real pecan instead of c++ logging

I never used cout-style logging in my kernels

#

I hate cout logging

#

It's so annoying

real pecan Apr 30, 2024, 12:18 AM

#

but u did something else and not printf iirc

flint idol Apr 30, 2024, 12:18 AM

#

It was indirectly calling printf

#

It was first printing what kind of log message it was

#

Whether it was a debug log, info/general log, warning, or error

#

then it printed the message

#

also I kind of forgot about error handling in the previous kernel

#

Something failed and you wanted to know why? Too bad, you're not going to

#

error codes were "false"

#

success was "true"

real pecan Apr 30, 2024, 12:21 AM

#

Lmao

flint idol Apr 30, 2024, 12:21 AM

#

isn't it three am where you are

#

probably a good idea to sleep

real pecan Apr 30, 2024, 12:23 AM

#

Indeed

flint idol Apr 30, 2024, 12:26 AM

#

It'd be funny if I implement a USB driver first thing after IRQL so I can send logs

#

and make a gdb stub for the kernel

real pecan Apr 30, 2024, 12:28 AM

#

That would be big

flint idol Apr 30, 2024, 12:29 AM

#

If I don't implement printing stuff on the framebuffer I'll be stuck with testing with qemu only

#

But I don't want to implement printing stuff on the framebuffer

#

because that's boring

#

I'll get to it eventually.

real pecan Apr 30, 2024, 12:30 AM

#

You could use flanterm

#

Or qr code generator

flint idol Apr 30, 2024, 12:30 AM

#

how would I use a qr code generator

#

for logs

real pecan Apr 30, 2024, 12:30 AM

#

Store logs in a buffer

#

On key press generate a qr code from that buffer

#

Display it

#

Done

flint idol Apr 30, 2024, 12:31 AM

#

pretty sure that's more work than just printing shit on the framebuffer

real pecan Apr 30, 2024, 12:31 AM

#

Yes and no

#

Framebuffer can only fit so much

#

And u cant ctrl+c from a framebuffer

flint idol Apr 30, 2024, 12:32 AM

#

Another problem with my previous kernel is that nothing was documented

#

There was no documentation, not even so much as comments explaining what the function does

#

None.

vernal chasm Apr 30, 2024, 12:33 AM

#

flint idol and make a gdb stub for the kernel

Make your own debugger api kekw

flint idol Apr 30, 2024, 12:34 AM

#

well I did make a kernel debugger for my previous kernel

#

that'd be the next step

#

obviously I should make a kernel debugger then add dwarf parsing so I can get line numbers

vernal chasm Apr 30, 2024, 12:37 AM

#

Sounds like pain

flint idol Apr 30, 2024, 12:37 AM

#

I think it is

vernal chasm Apr 30, 2024, 12:37 AM

#

Probably less pain than dealing with timer sync

#

kekw

flint idol Apr 30, 2024, 12:38 AM

#

for the dwarf part

#

A basic kernel debugger is pretty simple

#

Took me a day to do it

flint idol Apr 30, 2024, 1:00 AM

#

Kernel logger is complete (port 0xE9 only for now)

#

The new kernel is no longer stable

#

It panics on every boot

#

Now where was I

#

ah yes IRQL

#

I got the IRQL system working

#

I just need to test it

#

It's so simple I can't think of ways to test it immediately

#

after testing that I'll make a spinlock

#

Not many ways to test that either

#

It (probably) won't break

#

Spinlocks will be a part of the Core namespace

#

IRQL is a part of that namespace aswell

#

Things in the core namespace cannot depend on anything (except basic kernel routines and other Core namespace members)

#

If they do the kernel can, and most definitely will at one point, go to shit

#

For example the scheduler code cannot depend on the logging code

#

nor can it depend on, for example the VMM code

#

Maybe the scheduler was a bad choice but you the point still stands

#

of course that code can depend on Core namespace code

#

that's kind of the entire point

flint idol Apr 30, 2024, 2:12 AM

#

Spin locks work I guess

#

So simple I cannot mess up

#

I "tested" them by locking the logging functions (as I should)

#

There was a bug in Core_SpinlockRelease

#

It was with irql.

#

I think the fact that I'm writing it in C has caused me to think more about namespaces and dependencies

#

I just pushed the code for the kernel logger, IRQL, and spinlocks.

#

Tomorrow I shall work on the scheduler

#

Then the PMM

#

Then I shall port the old kernel's allocator

#

Then VMM and page cache shit

#

Then drivers

vernal chasm Apr 30, 2024, 2:23 AM

#

write gpu driver O_O

flint idol Apr 30, 2024, 2:23 AM

#

Eventually

vernal chasm Apr 30, 2024, 2:24 AM

#

Oh god

#

Gl at that point

flint idol Apr 30, 2024, 2:24 AM

#

I told @livid oracle I would here #349857717445459968 message

vernal chasm Apr 30, 2024, 2:24 AM

#

True true

#

But still good luck tho

#

O_O

flint idol Apr 30, 2024, 2:24 AM

#

But that's in a long time

#

I barely understand what graphics is

#

like what the hell does a geometry shader do?

#

make shapes?

vernal chasm Apr 30, 2024, 2:26 AM

#

flint idol like what the hell does a geometry shader do?

Takes in some number of primitives and produces new primitives

#

The fewest input primitives are singular points

#

And the fewest output primitives are singular points

flint idol Apr 30, 2024, 2:26 AM

#

I know what I should do

#

Port the windows driver interface

vernal chasm Apr 30, 2024, 2:26 AM

#

But you can produce any number of points from that singular point.
Or any number of lines or triangles

flint idol Apr 30, 2024, 2:27 AM

#

1:1, they won't notice a thing

#

then use windows graphics drivers

vernal chasm Apr 30, 2024, 2:27 AM

#

However it's technically limited up to some max number which you pre specify in the shader

#

But I'm not entirely sure if the driver has to conform to that limit

flint idol Apr 30, 2024, 2:28 AM

#

I'll port the WDF and have my own driver interface aswell

#

then I get graphics for free

#

and other drivers for dumb devices

#

anyway enough osdev for today

livid oracle Apr 30, 2024, 2:44 AM

#

flint idol like what the hell does a geometry shader do?

geometry shaders make people very upset and tell you to use mesh shaders KEKW

vernal chasm Apr 30, 2024, 2:44 AM

#

Wait why you in here O_O

#

kekw

livid oracle Apr 30, 2024, 2:44 AM

#

I am everywhere

vernal chasm Apr 30, 2024, 2:44 AM

#

Spooky

#

Wait so are you in #614652561965711370?

#

Probably not

#

Only like 4 people there so xD

#

Two of which are me...

#

lmao

livid oracle Apr 30, 2024, 2:45 AM

#

that you know of evil

vernal chasm Apr 30, 2024, 2:45 AM

#

Now I'm scared

livid oracle Apr 30, 2024, 2:45 AM

#

anyhoo it's time for me to disappear

devout niche Apr 30, 2024, 11:03 AM

#

flint idol Ok now IRQL

are you employing %cr8 for that?

devout niche Apr 30, 2024, 11:04 AM

#

flint idol I'll port the WDF and have my own driver interface aswell

good luck

#

WDF is large

flint idol Apr 30, 2024, 11:16 AM

#

devout niche are you employing %cr8 for that?

Yup

flint idol Apr 30, 2024, 9:33 PM

#

I'm writing all code related to thread context in assembly

#

Why you might ask? Because I can't be bothered to write a setup context in C then translate the C struct for context into assembly for the context switch function.

flint idol Apr 30, 2024, 11:31 PM

#

I've implemented those functions

#

Time to test them

#

I also have a thread structure

#

Lets see will I finally make stable kernel

#

Bro

#

I'm triple faulting randomly

#

WHYYYYYYY

#

nooo

#

oh of course it triple faults calling a function

#

We just love OSDev

#

The instruction that page faults, causing the triple fault is push rbp

#

then cr2 is 0x80

#

rsp is a good value

#

so is rbp

#

not that that would matter

#

no register is 0x80

#

there is no possible way for this to fail unless some dumb code overwrote the instruction

#

it's triple faulting on return?

#

The hell

#

Why is RIP the start of getIntIST then?

#

Why is this randomly triple faulting

#

the red zone is disabled

#

Qemu is cursed

#

I have more assembly in my kernel than C

#

unless header files count

#

I think it might be a bug with spinlocks somehow

#

const bool expected = true;
irql newIrql = Core_GetIrql() < minIrql ? Core_RaiseIrql(minIrql) : IRQL_INVALID;
while (atomic_compare_exchange_strong(lock, &expected, false))
    spinlock_hint();```

#

whoops

#

Nope

#

It isn't

#

It can't be a problem with some timer IRQ coming in

#

cr8 is 0xf

#

which blocks all IRQs

#

oh and of course when I add -no-shutdown -no-reboot to the qemu command line it doesn't triple fault

#

wtf is happening

#

In a debugger it triple faults

#

outside a debugger it doesn't

#

it hangs I think?

#

It's stuck in an infinite gpf loop because there is no handler

#

which spit a 593 MiB qemu log

real pecan May 1, 2024, 12:04 AM

#

flint idol oh and of course when I add `-no-shutdown -no-reboot` to the qemu command line i...

Bro how is it already unstable

flint idol May 1, 2024, 12:05 AM

#

It can't even be my fault

#

There is no code

#

It's page faulting on

#

address 0x80

#

THERE IS NOTHING THAT CAN ACCESS 0x80 at the faulting RIP

#

It's a push rbp with an intact stack pointer

real pecan May 1, 2024, 12:06 AM

#

Single step with gdb

flint idol May 1, 2024, 12:06 AM

#

That's what I'm trying

#

but it triple faults at random points

#

(of course only in a debugger)

#

nvm

#

Still triple faults at random points

#

I'm calling TCG bug

#

There is no other way

#

I'll use whpx as my accelerator

#

lo and behold it doesn't triple fault

#

My thread context switching code doesn't work

real pecan May 1, 2024, 12:09 AM

#

flint idol I'm calling TCG bug

X to doubt

flint idol May 1, 2024, 12:10 AM

#

I ran with whpx

#

It worked as expected

real pecan May 1, 2024, 12:10 AM

#

Timing issue

#

TCG doesn't have bugs

#

Or I doubt u can trigger them with such simple code

flint idol May 1, 2024, 12:14 AM

#

There is the qemu log

📎 qemu_log.txt

#

The instruction at RIP is push rbp

#

The part where it triple faulted is at the end

real pecan May 1, 2024, 12:15 AM

#

Send the report to qemu mailing list

weary hound May 1, 2024, 12:15 AM

#

tip: -M smm=off

real pecan May 1, 2024, 12:15 AM

#

But 99.9999999% sure its a you issue

flint idol May 1, 2024, 12:15 AM

#

I'd test on real hardware right now

#

But I have no way to print logs

#

on real hardware

#

rn

real pecan May 1, 2024, 12:16 AM

#

See if it triple faults or not

#

But like I said it can just be a timing issue

#

Which it probably is

flint idol May 1, 2024, 12:18 AM

#

real pecan But like I said it can just be a timing issue

wdym by timing issue

#

btw it doesn't triple fault

real pecan May 1, 2024, 12:18 AM

#

Print out the contents of rsp

#

In the fault handler

real pecan May 1, 2024, 12:18 AM

#

flint idol btw it doesn't triple fault

On real hw?

flint idol May 1, 2024, 12:18 AM

#

on real hardware

real pecan May 1, 2024, 12:18 AM

#

Anyway

flint idol May 1, 2024, 12:18 AM

#

btw this triple fault is happening before initialization of the gdt

#

and idt

#

so no fault handlers for me

#

it's happening while logging initialization of the GDT

real pecan May 1, 2024, 12:19 AM

#

You think basic code like that causes a TCG bug?

flint idol May 1, 2024, 12:19 AM

#

probably not

#

but you never know

#

I'll test on wsl's qemu

real pecan May 1, 2024, 12:20 AM

#

Try it

flint idol May 1, 2024, 12:20 AM

#

btw this only happens while a debugger is connected to qemu

#

maybe that has something to do with it

weary hound May 1, 2024, 12:22 AM

#

what is your gdt?

flint idol May 1, 2024, 12:22 AM

#

null segment 0x00

#

kernel code 0x08

#

kernel data 0x10

#

tss 0x18

real pecan May 1, 2024, 12:22 AM

#

I thought your gdt worked

#

How is it dying now

weary hound May 1, 2024, 12:22 AM

#

are you still using limine gdt at the point of the crash?

flint idol May 1, 2024, 12:22 AM

#

Well I'm using hyper's

weary hound May 1, 2024, 12:22 AM

#

judging by cs=0x28

flint idol May 1, 2024, 12:23 AM

#

but yes

weary hound May 1, 2024, 12:23 AM

#

is 0x10 a 64-bit data segment?

#

i have a feeling it's like 16-bit or 32-bit

#

or did you not touch the segment selectors yet

flint idol May 1, 2024, 12:23 AM

#

I hadn't touched them at the time of triple fault

weary hound May 1, 2024, 12:24 AM

#

hm what if you do x/i 0xffffffff800044b1 in the qemu monitor when it crashes

#

as opposed to objdumping or addr2line-ing the binary

real pecan May 1, 2024, 12:25 AM

#

TCG has no gdt validation basically

#

So even if u put garbage there it doesn't matter

weary hound May 1, 2024, 12:25 AM

#

well it's apparently before the gdt init

#

so it's still the bootloaders gdt

real pecan May 1, 2024, 12:26 AM

#

Yeah should be fine

flint idol May 1, 2024, 12:26 AM

#

What the hell, it stopped triple faulting

#

I add some code back it triple faults

real pecan May 1, 2024, 12:27 AM

#

This is the hyper bios gdt here at the bottom https://github.com/UltraOS/Hyper/blob/master/loader/arch/x86/bios/bios_entry.asm

GitHub

Hyper/loader/arch/x86/bios/bios_entry.asm at master · UltraOS/Hyper

A modern x86/ARM bootloader supporting both BIOS and UEFI - UltraOS/Hyper

flint idol May 1, 2024, 12:28 AM

#

why doesn't your gdt have a 64-bit code segment?

#

*data

real pecan May 1, 2024, 12:29 AM

#

Thats not a thing I think? (or at least it doesn't matter)

flint idol May 1, 2024, 12:29 AM

#

It is a thing

#

and I'm pretty sure it matters

weary hound May 1, 2024, 12:30 AM

#

you can just set all the other segment selectors to 0 for the kernel

#

but you need a valid segment for ss in user mode

real pecan May 1, 2024, 12:30 AM

#

flint idol and I'm pretty sure it matters

Doubt

flint idol May 1, 2024, 12:30 AM

#

maybe not though

#

idk

#

all I know about gdt is "make once, never think back"

real pecan May 1, 2024, 12:30 AM

#

Yeah at ring 0 u can just set them to 0

weary hound May 1, 2024, 12:30 AM

#

such a weak mindset, you wouldn't last a minute in protected mode on the 286

real pecan May 1, 2024, 12:31 AM

#

CS is still used for privilege checks I think

flint idol May 1, 2024, 12:31 AM

#

weary hound such a weak mindset, you wouldn't last a minute in protected mode on the 286

Exactly why I use long mode

real pecan May 1, 2024, 12:32 AM

#

And 64-bit data segment is not a thing right? @weary hound

weary hound May 1, 2024, 12:32 AM

#

it is a thing, as i said you need a valid segment for ss in ring 3 in long mode

real pecan May 1, 2024, 12:33 AM

#

That bit is valid only for the code segment

#

So I dont think so

weary hound May 1, 2024, 12:33 AM

#

or wait hold on

#

    common::x86::makeGdtFlatData32UserSegment(gdt, kGdtIndexClientUserData);

real pecan May 1, 2024, 12:34 AM

#

Yup

weary hound May 1, 2024, 12:34 AM

#

my bad, the data segment is the same for 32-bit and 64-bit

flint idol May 1, 2024, 12:35 AM

#

that leaves me wondering why [this](#curated-resources message) says 64-bit user data segment

#

and 64-bit data segment

#

probably because it's less confusing for beginners

real pecan May 1, 2024, 12:35 AM

#

Saga skill issue

weary hound May 1, 2024, 12:35 AM

#

compare the values though

#

they are the sam

#

e

flint idol May 1, 2024, 12:35 AM

#

well it was pitust's message

real pecan May 1, 2024, 12:36 AM

#

weary hound they are the sam

Nope

#

Look carefully

weary hound May 1, 2024, 12:36 AM

#

oh i see

flint idol May 1, 2024, 12:37 AM

#

but using x/i at the address in qemu

#

gives me push rbp

lean glen May 1, 2024, 12:37 AM

#

yea your stack is wrong

flint idol May 1, 2024, 12:37 AM

#

it isn't though

#

The stack is fine

real pecan May 1, 2024, 12:37 AM

#

The first unstable kernel pre gdt init

flint idol May 1, 2024, 12:37 AM

#

The cr2 value is fucked

lean glen May 1, 2024, 12:37 AM

#

flint idol The stack is fine

is it

flint idol May 1, 2024, 12:37 AM

#

rsp=0xffff80001ffb0ed8

#

cr2=0x0000000000000080

real pecan May 1, 2024, 12:38 AM

#

Bruh

weary hound May 1, 2024, 12:39 AM

#

real pecan Nope

okay no what's posted in curated resources is correct, the 32-bit segment has flags.DB=1 set and flags.L=0, and the 64-bit segment has flags.DB=0 and flags.L=1, which is what you are supposed to do apparently

#

quoth the osdev wiki gdt page

L: Long-mode code flag. If set (1), the descriptor defines a 64-bit code segment. When set, DB should always be clear. For any other type of segment (other code types or any data segment), it should be clear (0).

#

oh wait no

#

that's specifically for code

real pecan May 1, 2024, 12:40 AM

#

Literally incorrect

#

Yeah

weary hound May 1, 2024, 12:40 AM

#

reading comprehension: 0

#

on my part

real pecan May 1, 2024, 12:40 AM

#

Lol

#

Pitust fell off

weary hound May 1, 2024, 12:41 AM

#

for a moment i thought managarm was doing something wrong :^)

real pecan May 1, 2024, 12:41 AM

#

Nah thats impossible halfmemeright

weary hound May 1, 2024, 12:42 AM

#

yeah how could i ever doubt it

#

anyway

flint idol May 1, 2024, 12:42 AM

#

The triple fault changes locations every crash

weary hound May 1, 2024, 12:42 AM

#

did you enable interrupts by accident? :^)

real pecan May 1, 2024, 12:42 AM

#

You sure interrupts are disabled

flint idol May 1, 2024, 12:42 AM

#

cr8=0xf

#

eflags.IF=1

weary hound May 1, 2024, 12:43 AM

#

are you sure the legacy pic is masked?

#

also IF=1 means they are on

real pecan May 1, 2024, 12:43 AM

#

weary hound are you sure the legacy pic is masked?

Bruh

flint idol May 1, 2024, 12:43 AM

#

oh yeah PIC doesn't go through APIC

#

silly me

#

and it isn't subject to cr8

#

amazing

#

it works

#

ie. doesn't triple fault

#

now I got a context switch function to debug

real pecan May 1, 2024, 12:44 AM

#

Big

weary hound May 1, 2024, 12:44 AM

#

very cool tcg bug halfmemeleft

real pecan May 1, 2024, 12:44 AM

#

Lmao

flint idol May 1, 2024, 12:44 AM

#

does hyper by any chance remap the PIC

real pecan May 1, 2024, 12:44 AM

#

It doesn't touch any hardware

flint idol May 1, 2024, 12:45 AM

#

well why cr2=0x80 is forever unknown

weary hound May 1, 2024, 12:45 AM

#

limine explicitly masks the pic

flint idol May 1, 2024, 12:46 AM

#

I'll call Arch_disablePIC before anything

ashen goblet May 1, 2024, 12:46 AM

#

I see obos v5 is released?

#

Problems with teiple faults i see?

real pecan May 1, 2024, 12:47 AM

#

TCG bugs halfmemeright

flint idol May 1, 2024, 12:47 AM

#

but why was cr2=0x80

weary hound May 1, 2024, 12:47 AM

#

flint idol well why cr2=0x80 is forever unknown

accessing the idt? idt=0x0000000000000000

flint idol May 1, 2024, 12:47 AM

#

but what vector

#

was it addressing

real pecan May 1, 2024, 12:47 AM

#

0

weary hound May 1, 2024, 12:47 AM

#

0x80 / 16 = 8

#

vector 8

flint idol May 1, 2024, 12:48 AM

#

oh yeah idt entry is 16 bytes

real pecan May 1, 2024, 12:48 AM

#

Or that

weary hound May 1, 2024, 12:48 AM

#

aka where the master pic is mapped by default

#

on bios

#

so irq 0 on master pic

#

aka pit

real pecan May 1, 2024, 12:48 AM

#

weary hound aka where the master pic is mapped by default

Oh interesting

flint idol May 1, 2024, 12:48 AM

#

I remember getting this bug on my first kernel

#

when I stied

#

Because I had no IDT

#

I had no idea why it happened

weary hound May 1, 2024, 12:49 AM

#

real pecan Oh interesting

yeah ibm didn't listen to intel saying that the first 32 vectors are reserved and now you end up with the pic in the middle of cpu exceptions on legacy bios

real pecan May 1, 2024, 12:49 AM

#

IBM big retard

weary hound May 1, 2024, 12:49 AM

#

although originally there was nothing there and no one could've predicted the pc would come out on top as the dominant platform so

ashen goblet May 1, 2024, 12:49 AM

#

weary hound yeah ibm didn't listen to intel saying that the first 32 vectors are reserved an...

So these dudes are the reason why we are forced to remap it

flint idol May 1, 2024, 12:50 AM

#

which is why we should make a time machine

#

go back in time

#

with the limine mafia

#

and threaten ibm to listen to intel

ashen goblet May 1, 2024, 12:50 AM

#

galaxybrain

#

And force every os to use limine

real pecan May 1, 2024, 12:50 AM

#

I would just buy Bitcoin

weary hound May 1, 2024, 12:50 AM

#

go back in time
tell ibm to map pic to vector 0x20
go back to the present
you are using a m68k computer now

real pecan May 1, 2024, 12:50 AM

#

Lol

flint idol May 1, 2024, 12:51 AM

#

lol

real pecan May 1, 2024, 12:51 AM

#

With keyronex as your daily driver

flint idol May 1, 2024, 12:51 AM

#

but why didn't it triple fault on my laptop

#

It should've because no hardware was touched

#

and it emulates the PIT

real pecan May 1, 2024, 12:51 AM

#

Pit not enabled by default

weary hound May 1, 2024, 12:52 AM

#

uefi machine?

flint idol May 1, 2024, 12:52 AM

#

indeed

#

oh yeah

#

I forgot that I would boot from legacy bios emulation (I forgor what it's called) on my laptop for my 2nd kernel

#

which is why I could use PIT

#

I should probably sleep even though it's pretty early

real pecan May 1, 2024, 12:53 AM

#

Same

flint idol May 1, 2024, 12:53 AM

#

if I'm forgetting stuff like this' this bad

flint idol May 1, 2024, 12:53 AM

#

real pecan Same

staying up to 4 am for osdev ain't a good idea

real pecan May 1, 2024, 12:53 AM

#

Yes

ashen goblet May 1, 2024, 12:54 AM

#

Dont give up now

#

KEKW

flint idol May 1, 2024, 12:54 AM

#

I obviously should've started rewrite six when I got the triple fault

real pecan May 1, 2024, 12:54 AM

#

Obos rewrite 6, remastered gdt init

ashen goblet May 1, 2024, 12:54 AM

#

😭

#

This time in Rust so you are safe from memory leaks triple faults scheduler bugs and allocator/vmm problems

flint idol May 1, 2024, 12:55 AM

#

I remember when my kernel wasn't cursed

#

t'was a long time ago

real pecan May 1, 2024, 12:55 AM

#

You will get there

flint idol May 1, 2024, 12:55 AM

#

eventually

real pecan May 1, 2024, 12:55 AM

#

Yes

ashen goblet May 1, 2024, 12:57 AM

#

Good luck

flint idol May 1, 2024, 12:57 AM

#

ty

#

for future reference, the align directive in nasm does nothing for struc alignment

#

only code alignment

#

and data

#

ok

#

after some debugging

#

I can switch to an "arbitrary" """thread""" context

#

static void test_function(uintptr_t userdata)
{
    OBOS_Debug("In %s, userdata: %lu.\n", __func__, userdata);
    while (1);
}```

#

is basically is getting called in a fancy way:

thread_ctx ctx;
memzero(&ctx, sizeof(ctx));
CoreS_SetupThreadContext(&ctx, test_function, 0x45, false, thr_stack, 0x4000);
CoreS_SwitchToThreadContext(&ctx);```

ashen goblet May 1, 2024, 1:03 AM

#

Hows memzero different / better than memset

flint idol May 1, 2024, 1:03 AM

#

it's not

#

I just like saying memzero

#

instead of memset

ashen goblet May 1, 2024, 1:04 AM

#

Thats a valid reason

flint idol May 1, 2024, 1:04 AM

#

~~I mean technically it's faster by a couple cycles~~

low lodge May 1, 2024, 1:04 AM

#

but why memzero and not OBOS_CoreS_MemorySetZero?

flint idol May 1, 2024, 1:04 AM

#

because

#

I don't wanna type all that

low lodge May 1, 2024, 1:05 AM

#

also valid

flint idol May 1, 2024, 1:05 AM

#

and the prefixes have a meaning

#

anything without the prefixes is rather statically linked or is something like memzero

#

or memset

#

or it's a type

#

types don't follow that rule

ashen goblet May 1, 2024, 1:05 AM

#

flint idol ~~I mean technically it's faster by a couple cycles~~

~~How, are you doing some aligned data shenanigans or simd stuff~~

flint idol May 1, 2024, 1:06 AM

#

No

low lodge May 1, 2024, 1:06 AM

#

wdym by statically linked? surely everything in the kernel is linked into the kernel

#

unless you have modules already

flint idol May 1, 2024, 1:06 AM

#

I meant static linkage

#

like the static keyword

low lodge May 1, 2024, 1:06 AM

#

ah, internal

flint idol May 1, 2024, 1:06 AM

#

It's just xor rax,rax takes fewer cycles than mov al, sil

#

so using memzero is faster

#

by a couple clock cycles

ashen goblet May 1, 2024, 1:07 AM

#

What if the data youre zeroing isnt in a register

flint idol May 1, 2024, 1:08 AM

#

rax is used for rep stosb

#

for the value to fill the memory in

ashen goblet May 1, 2024, 1:09 AM

#

oh yeah i remember

#

al in the case of stosb tho right

flint idol May 1, 2024, 1:09 AM

#

I'm not sure if I'm lagging or discord is

flint idol May 1, 2024, 1:09 AM

#

ashen goblet al in the case of stosb tho right

but yeah

flint idol May 1, 2024, 1:10 AM

#

flint idol I'm not sure if I'm lagging or discord is

I see a notification (I have notifications for this thread on all)

#

I open discord

#

and there is no message

#

until I reopen discord

ashen goblet May 1, 2024, 1:10 AM

#

Common discord L

weary hound May 1, 2024, 1:11 AM

#

flint idol It's just `xor rax,rax` takes fewer cycles than `mov al, sil`

and xor eax, eax is better still, since it's 1 byte shorter (=> 1 byte freed up in the icache)

flint idol May 1, 2024, 1:11 AM

#

good idea I should do that

low lodge May 1, 2024, 1:11 AM

#

The real question is whether you have memzero call memset or if its handmade - the compilers specially optimize specifically memset, so if you're handrolling something you're likely leaving perf on the table

flint idol May 1, 2024, 1:12 AM

#

I got memset implemented

#

using rep stosb

#

I optimized memzero

#

to be one byte shorter

low lodge May 1, 2024, 1:12 AM

#

https://godbolt.org/z/Yeco3zPha as an example, memset doesn't even exist in this TU but the compiler still magically optimizes it to rep stosq

Compiler Explorer - C (x86-64 gcc 13.2)

void *memset(void *, int, unsigned long);

static int memzero(void *ptr, int len) {
memset(ptr, 0, len);
}

void foo(int *);

int main() {
int x[1000];
memzero(x, 1000 * sizeof(int));
foo(x);
}

sharp pike May 1, 2024, 1:12 AM

#

not with -ffreestanding

low lodge May 1, 2024, 1:13 AM

#

oh really?

sharp pike May 1, 2024, 1:13 AM

#

because it implies -fno-builtin

low lodge May 1, 2024, 1:13 AM

#

I thought that magic was always magic

sharp pike May 1, 2024, 1:13 AM

#

nope

#

try it

low lodge May 1, 2024, 1:13 AM

#

you're right indeed

#

though -ffreestanding -fbuiltin brings the behavior back, idk if that has other bad side effects for a kernel though

sharp pike May 1, 2024, 1:14 AM

#

i mean yeah because you're re-enabling it

flint idol May 1, 2024, 1:14 AM

#

btw what happened to banter

sharp pike May 1, 2024, 1:15 AM

#

it means that you have to implement standard behaviour for function calls, and that you also have to be careful when implementing stuff because for example the compiler could optimise a memset() impl to a memset call

#

as you showed there

#

which is not very good

flint idol May 1, 2024, 1:15 AM

#

which is why you should ditch compilers

#

and code everything in asm

sharp pike May 1, 2024, 1:15 AM

#

in general you can reenable -fbuiltin but it requires you to be extra careful about stuff like that

flint idol May 1, 2024, 1:15 AM

#

not just x86_64 asm

#

8086 asm

sharp pike May 1, 2024, 1:15 AM

#

no

flint idol May 1, 2024, 1:16 AM

#

I have more asm in my kernel than C code

#OBOS (not vibecoded)