spare has quit [Remote host closed the connection]
theyneversleep has joined #osdev
xenos1984 has quit [Quit: Leaving.]
xenos1984 has joined #osdev
mpetch has quit [Ping timeout: 240 seconds]
Left_Turn has joined #osdev
housemate has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
housemate has quit [Ping timeout: 252 seconds]
jedesa has quit [Remote host closed the connection]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 265 seconds]
netbsduser has joined #osdev
goliath has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 252 seconds]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
GeDaMo has joined #osdev
craigo has quit [Quit: Leaving]
beto has quit [Ping timeout: 245 seconds]
beto has joined #osdev
hwpplayer1 has quit [Ping timeout: 260 seconds]
theyneversleep has quit [Remote host closed the connection]
gareppa has joined #osdev
gareppa has quit [Client Quit]
theyneversleep has joined #osdev
steelswords94 has joined #osdev
steelswords94 has quit [Ping timeout: 248 seconds]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
x64S has quit [Ping timeout: 252 seconds]
Arthuria has joined #osdev
theyneversleep has quit [Remote host closed the connection]
steelswords94 has joined #osdev
vdamewood has quit [Quit: Life beckons]
steelswords943 has joined #osdev
steelswords94 has quit [Ping timeout: 248 seconds]
steelswords943 is now known as steelswords94
Dead_Bush_Sanpa1 has joined #osdev
Dead_Bush_Sanpai has quit [Ping timeout: 252 seconds]
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
ThinkT510 has quit [Remote host closed the connection]
ThinkT510 has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
goliath has quit [Ping timeout: 276 seconds]
goliath has joined #osdev
gildasio has quit [Ping timeout: 264 seconds]
gildasio has joined #osdev
<_ngn>
when an interrupt occurs at ring 3, the cs and rip is obtained from the IDT entry for that inerrupt, right? and the rsp is obtained from the TSS(.rsp0)? then how do we obtain the ss?
<zid`>
ss=ds
<zid`>
long mode is forced-flattened and ds=es=ss
<_ngn>
yeah how do we obtain it
<zid`>
'obtain'?
<zid`>
mov ax, ss
<_ngn>
i mean how does the cpu interrupt it
<zid`>
interrupt what?
<_ngn>
when an interrupt occurs at ring 3, like say a PF
<_ngn>
the cpu gets the cs and rip from the IDT entry right?
<zid`>
yes
<_ngn>
and we get the rsp from TSS?
Arthuria has quit [Ping timeout: 276 seconds]
<zid`>
yes, you already said these bits
<_ngn>
i mean the cpu gets rsp from the TSS right?
<_ngn>
yeah
<_ngn>
so how does it obtain the ss?
<zid`>
it doesn't need to
<zid`>
long mode is flat
<zid`>
you have a hard-coded kernel data descriptor
<_ngn>
so we just use the user's ss
<zid`>
that you should use for ds, es, and ss
<_ngn>
what
<_ngn>
so i dont need a data segment entry in my gdt?
<zid`>
You need one for kernel, one for user
<_ngn>
yes so when the interrupt occurs its using the users entry
<zid`>
and both their respective one with all of their selectors other than cs
<_ngn>
so the cpu uses the users SS when an interrupt occurs?
<zid`>
I think it actually just ignores it in long mode
<zid`>
in cpl0
<zid`>
I'd have to check the manual
<zid`>
but, it's always the same selector, and you know what it is, so you can just load it into ss/ds if you want
<zid`>
It also allows ss=0 inside nested interrupts I think
<_ngn>
im just tryna figure out why i get a stack segment fault when i interrupt from the userspace
<zid`>
The new SS is set to NULL if there is a change in CPL
<zid`>
6.14
<zid`>
You get exception 12 inside your irq handler?
<_ngn>
nah the handler doesnt even get called
<zid`>
not an irq problem then
<zid`>
that's just an exception that some code caused
<zid`>
if it couldn't deliver the interrupt, it'd double fault
<zid`>
then triple fault if it still couldn't
<_ngn>
like right after the "int" instruction in the userspace i get a 0xc
<zid`>
oh, int, not an irq
<zid`>
I've never ran int in long mode, heh
<zid`>
Kind of forgot it even existed ngl
<_ngn>
oh im not supposed to?
<zid`>
I mean, it isn't the syscall interface anybody uses
<zid`>
because long mode has its own, fast one
<_ngn>
ik im just using it for testing
<zid`>
I only take interrupts from ring3 as exceptions/irqs
<_ngn>
other interrupts like exceptions do not work either
<zid`>
things that can cause #ss: stack operation that's outside the base/limit, which isn't an issue in long mode
<zid`>
non-present stack segment when loading ss, which I think only applies to us for iretq
<zid`>
and non-canonical stack access
<zid`>
which is very possible
<zid`>
if you're in qemu, do you get an e=0000 v=0012 etc line with -d int you can quickly share?
<zid`>
0x0FFDF00000000000 is definitely non-canonical
<zid`>
and will cause an #SS
<_ngn>
prev it was the other way around
<zid`>
neither of those should be where you think your kernel heap is
<_ngn>
it was 000000000ffdf000
<zid`>
that's at least canonical, but insane
<zid`>
2.6GB into low memory lol
<_ngn>
its end of the page i allocated for the stack
<zid`>
oh is it at exactly 255MB
<zid`>
and I off by 10
<zid`>
Why is your heap at 255MB in virtual memory?
<_ngn>
please dont question my shit memory managment
<zid`>
instead of at say, -256GB, nearly 128 terrabytes away
<zid`>
well, whatever, it shouldn't cause an #SS if you revert it to be correct at least
<zid`>
so your actual #SS is still a mystery
<zid`>
do you have like, something I could run
<_ngn>
so which is the correct one
mpetch has joined #osdev
<zid`>
well one of them is very incorrect, one of them is just weird
<_ngn>
im still confused
<zid`>
so go with the weird one
<zid`>
It was supposed to just be a 2 second "x /16bx 0xaddressoftss"
<zid`>
to make sure rsp wasn't ending up stupid
<zid`>
but you kept dumping it weird and taking 4 mins between attempts
<_ngn>
the actual value my allocation function returns is 0xffde000, i add 4096 (bc i allocated exactly one page) and i get 0xffdf000
<zid`>
yea it's just a weird address, it's canonical
<_ngn>
so the first 16 bytes should like 0x0ffdf00000000000 0x0000000000000000 right?
<zid`>
no, that means reserved = 0x0000DFFF, rsp = 0
<zid`>
err no, math, still, close enough
<mpetch>
Have a repo?
<zid`>
I'd love a binary
<_ngn>
zid`: i think those 16 bytes are correct
<zid`>
oh, because you dumped them as giant hex, right
<_ngn>
bc when i print tss+4 i get the correct rsp address
<zid`>
fuck
<zid`>
why are they dumped as giant hex "(£*")osd[ps[opda
<_ngn>
yeah i like doing gx a lot
<_ngn>
lol
<zid`>
I j ust wanted, fucking 16bx, 30 mins ago :(
<zid`>
sorry, 40 m
<_ngn>
sorry i totally wasted both of our time
<zid`>
so, got a binary?
SophiaNya has quit [Remote host closed the connection]
ptrc has quit [Remote host closed the connection]
ptrc has joined #osdev
SophiaNya has joined #osdev
<heat>
on one hand, i'm watching paint try again
<heat>
otoh, no way im debugging descriptor table problems lol later losers
<zid`>
it's shitty cmake paint though right, not even good paint?
<heat>
nah it's python now
<heat>
cmake has dried up
<zid`>
eww python paint
<heat>
fairly quick for a rebuild though, some 5 minutes
<heat>
OPTIMAL FAST ONYX OPERATING SYSTEM
<mpetch>
If this is your Github (which is active today, so assume it might be yours?) https://github.com/ngn13/sdx.git then you could just push your latest code and we could take a look.
troseman has joined #osdev
troseman has quit [Client Quit]
<_ngn>
mpetch: see tss branch, i was cleaning up my "expirements" so i could commit the changes
<nikolar>
yeah python isn't too bad to build
<heat>
i might repackage stockfish today in honor of blundering world championships
<nikolar>
lol
<zid`>
you blundered? dang ding
<heat>
stockfish is just a really nice port because it's just really standard C++ with a gnu makefile
<heat>
no crazy deps
<zid`>
heat: Are you ding or gukesh?
<heat>
no, im garry chess, creator of chess
<zid`>
oh neat
<zid`>
If chess is so good though, why is chess 2 not on steam?