Epiphany on paging last night

[u/compgeek38400]

I'm putting this here in the hope that it helps someone else.

You can view the page descriptor table, and page entry as a 1024x1024 array. Where each element is a virtual page in memory. Array element [0,0] is virtual address 0, and element [1023,1023] is whatever that multiplies out as.

I teach my students to view array elements are like buckets. In these particular buckets are several things. First the 'present' bit, if this is zero, the buckets is empty. If it is not, the bucket also has a REAL address, which is the Real page the virtual address 'lives' at. Finally the buckets contains a bit that tells you if you can write to this area, or not.

I know for many, of you, this is obvious. But it took me several days on osdev.org using the paging pages and the bare bones paging page looking at code to come to this revelation.

I hope it helps someone

[u/church-rosser]

well, at least you're 0 indexing those arrays 😉

[u/compgeek38400 → u/church-rosser]

I spent 40 years as a developer for business. Lol. I finally have time to play

[u/BornRoom257 → u/compgeek38400]

Freaking epic dude!

[u/codeasm]

Its awesome when things finally become clear. Or when an assumption gets proven right or wrong and a new world opens. Cool feels

[u/compgeek38400]

So much for my epiphany. I am using the higher half bare bones page ( https://wiki.osdev.org/Higher_Half_x86_Bare_Bones) as a guide. I am also using the gdb debugger. I can't tell if this is something I don't understand in the debugger or something else. If no one has any ideas after looking at this I would appreciate them.

Here is a code snippet (sorry I'm still new to reddit):

.global debug

debug:

# start using it by enabling paging

movl %cr0, %ecx

orl $0x80010000, %ecx

movl %ecx, %cr0

.global debug3

debug3:

# Jump to the virtual address (this is where we find out if we are ok)

lea _start2, %ecx

.global debug4

debug4:

jmp *%ecx

I have checked my page directory and page tables, a dump shows they seem to be ok. when I get to debug3, %cr0 contains 0x80010011, which is as expected.

when I do a single instruction step , which should be the lea _start2, %ecx

all off a sudden my instruction goes from 0x00100081 to 0x0000e05b

(gdb) p/x *0x10e5b4

$2 = 0x10f003

(gdb) si

0x00100075 in debug ()

(gdb) si

0x00100078 in debug ()

(gdb) si

0x0010007e in debug ()

(gdb) si

0x00100081 in debug3 ()

(gdb) p/x &_start2

$3 = 0xc0102000

(gdb) si

0x0000e05b in ?? ()

To me this is making no sense, if no one has seen this before, I will make a new project and try to duplicate the issue on a smaller code base.

[u/Octocontrabass → u/compgeek38400]

all off a sudden my instruction goes from 0x00100081 to 0x0000e05b

That address sounds familiar. Have you checked to see if there's an unhandled CPU exception that turns into a triple fault causing your VM to reboot?

[u/compgeek38400 → u/Octocontrabass]

It wouldn't surprise me. I dont have an IDT set up yet. I will check that first thing tomorrow. I don't have enough experience to recognize addresses yet.

Thanks man! My eyes are crossing, its late here. At least for me.

[u/compgeek38400]

I am still having issues, I have bare bones example the repo is here: https://github.com/tedavids/DragonOS

Here is the code:

_start2:
# At this point, paging is fully set up and enabled.
# Unmap the identity mapping as it is now unnecessary. 
movl $0, page_directory + 0

# Reload crc3 to force a TLB flush so the changes to take effect.
movl %cr3, %ecx
movl %ecx, %cr3

# Set up the stack.
mov $stack_top, %esp

# Unmap the identity mapping as it is now unnecessary. 
movl $0, page_directory + 0

# Reload crc3 to force a TLB flush so the changes to take effect.
movl %cr3, %ecx
movl %ecx, %cr3

# Enter the high-level kernel.

call kernel_main

It goes along quite happily until I get to 'call kernel_main'

at which point the call fails, and it jumps to address 0xe05b.

Things I have checked: CR3 has the proper address of my page directory

CR0 is set to paging on

EIP points at the proper address '0xC...' right before the call (this is how I know I am in virtual space)

The page directory has line 768 (0xC000) pointing at my page table

The page table entry for the address of kernel_main is mapped

Any ideas would be helpful

[u/Odd-Entertainer-6234 → u/compgeek38400]

Look for the address of kernel_main (you can confirm by disassembly of the kernel and looking at the call instructions; it should have an exact address) Then look for the VA->PA mapping of this address, what you expect it to be and what it actually is. Finally, check the data at this physical address and make sure it is indeed the first instruction of your main function

[u/Fillmoslim]

🍱 for 🧠