#EvalynOS
1 messages · Page 7 of 1
But other usb drivers would be userspace
And userspace will have a way to send and retrieve whatever it wants to usb ports
ooh
So you can boot from USB and have usb input always without depending on userspace
noicee yeah that woudl be nice
im close to giving up
i swear
aaaaaaaaaaaaaaaaaaaaaaaaaa
they're all in vacation
Damn
Honestly @devout path
Do you wana just rewrite this from scratch?
And put this commit to shreds
It might be better to just recode this from scratch 💀
y e s
hub
Uhhhhhhhhhh
I never made a commit
I was gonna but
this is why u make commits XD
xd yes
@devout path this would mean you could probably fully PR this commit tbh
Because it’s a lot more of a minimal change your your doing most of it 
yeeeeeeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
i m eaaan ;-;
What
yeah why not XD
it'll take me a while if i don't get toolazy
Get your name in the open source
hmm?
Or somthing I dunno 
Just like your GitHub account would be linked to the commits
But yeah wtf is up with these bugs
i have 0 clue
Like where the fuck in the code is causing it
hooooooonestly
Maybe use a per thread global instead of gs @devout path and refer to it from assembly and for many cores make it an array
hmmm yes yes
And then index by current core ID from reading the MSR that has that
Wait wait
@devout path what if you use the kernel base gs
hmmmmmmmm
And change the write to the KBASEGS MSR
could work
And then in the start of the kernel run a swapgs
@viral bison mentioned UBASEGS caused issues
hmm ye syes
Plus the kernel using the KERNEL base gs would make more sense
yeah true
hmm?
wdym
can u test it for me pls
am not doin it rn i have life stuff xd
all roads lead to albuquerqe
wat
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhuh
no yeah
errrr
btw whys 0x06 on the IP
CR2=0x0000000000000006
of all things
f
mov [gs:32], rsp
mov rsp, [gs:24]
...
mov [gs:24], rsp
mov rsp, [gs:32]
this is correct rigjt
yes
but
h u h
w h a
honestly atp
i have no clue whatsover
is there anyone we know that can help
whats up
SYSRET is a companion instruction to the SYSCALL instruction. It returns from an OS system-call handler to user code at privilege level 3. It does so by loading RIP from RCX and loading RFLAGS from R11.1 With a 64-bit operand size, SYSRET remains in 64-bit mode; otherwise, it enters compatibility mode and only the low 32 bits of the registers are loaded.
hm @devout path
hmmmmmmmm
SYSCALL invokes an OS system-call handler at privilege level 0. It does so by loading RIP from the IA32_LSTAR MSR (after saving the address of the instruction following SYSCALL into RCX). (The WRMSR instruction ensures that the IA32_LSTAR MSR always contain a canonical address.)
SYSCALL also saves RFLAGS into R11 and then masks RFLAGS using the IA32_FMASK MSR (MSR address C0000084H); specifically, the processor clears in RFLAGS every bit corresponding to a bit that is set in the IA32_FMASK MSR.
do we clobber RCX anywhere
or R11
yes
if i change from sysretq to sysret i fer a diffrent error
wat error
idk
true..
src/kernel/interupts/syscall.asm:55: error: label sysretq' alone on a line without a colon might be in error [-w+error=label-orphan]`
h u h
n e a t
yes
neat
whats these
src/kernel/interupts/interupts.asm:38: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
make[1]: *** [GNUmakefile:235: obj-x86_64/src/kernel/interupts/interupts.asm.o] Error 1
make[1]: *** Waiting for unfinished jobs....
src/kernel/interupts/syscall.asm:32: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
make[1]: *** [GNUmakefile:235: obj-x86_64/src/kernel/interupts/syscall.asm.o] Error 1
call dispatch_interupt
doesn't work
prolly has dsometing to do with that
idk if that is actually the prob
works now?
fixing the assembly
what was wrong with it?
why not just call dispatch_int?
how do you compile your assembly
nasm
yes.....
it errors
src/kernel/interupts/syscall.asm:32: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
and the other way will too
64-bit absolute section-crossing relocation [-w+error=reloc-abs-qword]

what is ur line 32
are you like putting this in some other section
elf section
default?
Same
@hazy saddle try to compile your OS with clang
assembly too
maybe it'll work better by using just 1 compiler for everything
in general you need to narrow the issue
it really seems you guys are just searching in the dark
well, we did find that it is somehow jumping to rdi
when it's pushed to the stack
or a bit later
Can clang compile NASM code?
yes, ofc
What flags should I change in the makefile
no
nasm syntax does happen to be very close to intel syntax so it might work
yeah i found something that needs fixing for it
and why change assemblers
its not
lemme finish to convert them
well ill just put it this way
if changing assemblers fixes something
there is some deeper issue
doesnt seem very productive
Does this happen with using the proper sysret instruction?
idk
Instead of whatever the fuck sysretq is
Maybe we just ignore the 32bit whatever NASM error garbage is
sysretq is what you should use (or in nasm o64 sysret, though sysretq probably works in nasm too idr)
because by default sysret is going to return to compatibility mode if you don't do that
ah then ig it only supports the o64 sysret variant
how do i fix this aswell?
src/kernel/interupts/interupts.asm:40: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
so i need another o64 on iretq?
probably yeah o64 iret
nope
src/kernel/interupts/syscall.asm:32: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
src/kernel/interupts/interupts.asm:40: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
both on the calls to c functions
leme just mute that
this is new
looks like its executing thr wrong systemcall
eg this 
I once spent a full day on debugging why my sysret didnt work. turns out nasm interpreted it as an incorrect label and threw a warning I didnt see
moral of the story is werror
GPF here now @devout path @viral bison
0xffffffff8000c1ea
dispatch_interupt_asm
src/kernel/interupts/interupts.asm:?
hmmm
whats the error code of the gpf
ERROR : 00000000 00000000 00000000 00010000
your IDT is so fucked btw
hm?
i'm fixing all of it

the IDT entry is completely wrong
bwuh
I dont believe you
give me qemu log

ooo my stack tarce worked for once here kinda
in debug mode it dosnt do tht garbage
@rancid viper
whats 0x10?
ah
so segment error on index 2 of the gdt
gdt_fill_entry (2, 0x92, 0xC); // 64 Bit Kernel Data | 0x10
hm
can you dump the gdt
how
also, why were you using 32 bit flags for your IDT?
etc etc
wut
is that not for user callable interupts?
no
?????
send me a link to their idt coide
yes it is
correct value for an interrupt gate here is to set flags to 0x8E
ah wait
flags covers present, dpl, gate type
i split the DPL that's why
in mean its on github too
my patchset isnt touching idt
Well because the random error code it gave I had to make the quick edit 
And because some how the error code is the only thing that did not break
triple fault after it runs a bit
But bad apple runs?
prob something wrong when executing syscalls
it spams the console
i think it's your printf
lamao
i go back
then i see this XD
wild
Probaly the printf systemcall
It’s probably getting a non null terminated string
enjoy
TF still maybe
Somewhat
It does run a bit tho
So it might be some syscall impl
Ans it uses clang now
what else did you change besides the IDT btw
Most of the asm files
git diff HEAD~1 HEAD
@viral bison gimme a patch file to apply to main
ima be back tmr i forgor i have a shit ton of things todo
if this not fixed till tmr im gonna try
try this
after i unzipped it, it showed all the files edited
patch too
the edits seems to be in the file modes
oh well
WSL?
evalyn? wsl?
who uses wsl nowadays
: )
CachyOS
wat wdym
It should work anyway
And use the one i sent?
Nasm is pain
The syntax is better for my mush brain
wait why idt change
I used macros to auto gen all the 256 interrupts
And then get the address of the handlers from an array
Set via asm
- some exception flags were wrong
I think the other way is fine and more explicit imo?
These need to be changed
I mean take those fixes
It would make a very long file
It's worse the way it was before
I'd help but I am currently working so 🙂
I’m gonna take a break
And play a game maybe
Maybe eat food
I haven’t eaten
In today
tbh
i suggest everyone to take a break from this os for a day XD
this made my brain mush more than it was
you should keep an up-to-date dev branch
because these patches and zip files makes it just unecessarily difficult to help
@hazy saddle pls :D

u can commit everytime u do a minor change
What do I name it
so i can develop on top of that with the block driver that im making
dev
make it weedbranch

then you can just cherry-pick and rebase everything u want to main
like I can understand wanting to keep a clean main
but this current system aint it
yes

Il call it dev
perfect
All commits Goto dev
And when it’s time for main
Il squash and then merge into main
iz it fine if u make me a collaborator
yez
prs exist too 🙂
Can I give you perms on the dev branch but not main?
It’s public
Okay I’m gonna get food and then get a commit with the gdt changes that were good
And then get the somewhat not working syscalls in dev
(In dev)
And then get @devout path and @viral bison as collabs on the dev branch
yes
pls don't foret to make it always up to date though ;-;
so i can alwys check it
I am making the executive decision to stick with NASM
As it’s what I’m used to and I prefer the syntax
Any changes I make il be sending to dev instead of a patch file
And then once we get a feature working it gets squashed to main
Also you want to get added to my personal dev server? so I can setup a bot with git notifications and for other generic chatting that may not be good for here lmao
Possibly helpful 
yes yes
And later il have an unstable branch once main is stable
So new features go there instead of main
Just incase
Then things go dev > unstable > main
yes yes perfefct
I think that milestone should be core utils + shell + nano + doom and ext2 and sata
yes yes
dm me if you want the inv
its for dev notis and non evalynos chat because yall friends :3
yippie
new proper dev branch for changes that may ior may not be buggy
the other option (which you cant do atm) is to fork and upstream
but that might be excessive for a personal project
@rancid viper progress and im about to push to dev
a few syscalls can be ran before death
and they are ones i expect
it is that invalid GPF error code
leme make a quick qemu log file
something is wrong w ur error print
if (frame != NULL) {
printf("ERROR : " BYTE_TO_BINARY_PATTERN " " BYTE_TO_BINARY_PATTERN
" " BYTE_TO_BINARY_PATTERN " " BYTE_TO_BINARY_PATTERN " \n",
BYTE_TO_BINARY(frame->error >> 24), BYTE_TO_BINARY(frame->error > 16),
BYTE_TO_BINARY(frame->error >> 8), BYTE_TO_BINARY(frame->error));
}
yeah error is still 0x10
but some systemcalls do get to be ran
oh wtf it's binary
yes
limit is ignored on x86-64
gdt_fill_entry (2, 0x92, 0xC); // 64 Bit Kernel Data | 0x10
why don't u make them constants
i dunno how
like u are calling a function that writes a value calculated from constants
Basically right?
wait ur flags are weird
huh
yes
i took the flags and accsess values from here
bit 2 of the flags for data segment should be set, its the 16-bit vs 32-bit data bit
and bit 2 of the flags for 64-bit code segment should be cleared (and instead bit 1 set)
this is a 64bit data segment
there is no such thing as a 64-bit data segment, it has the same format as a 32-bit data segment
bit 1 is only for code segments no?
afaik bit 0, 1, 2 should be clear for a 64bit data segment?
oh I misread ur thing
lol
idk if it matters in 64-bit tbh, it might not
what bits should 0x10 have on flags
granularity at least prob doesnt? since limit and base are ignored
no u have it correct
qwinci corrected me
well start by dumping the instructions where it happened so we know at least what it was trying to do
i dont think this is the right IP?
the IP lands somwhere here
wait no
its just a random match
evalyn@EvalynPC î‚° ~/Documents/Programming/C/evalynOS î‚° î‚ master ±✚ î‚° addr2line -fai -e kernel.elf 0xffffffff8000c1ea
0xffffffff8000c1ea
dispatch_interupt_asm
src/kernel/interupts/interupts.asm:?
but yeah the IP seems widly off
pushed to dev
here we go
ah
well can u dump the stack at the time of exception
most likely something is wrong with the iret frame ig
Is there a good way to set a breakpoint there but only have it trigger when it’s about to do the GPF?
u can just dump using qemu monitor after the fact
I don't think it consumes the frame if u fault
thought not 100% sure on that one
Completely fair
nice!
i got CPUID working in the meantime
And if on physical hardware the frame buffer will get WC enabled to speed it up
hmmmmmmmmmmmmmmmm
huh wtf
between the printf and the switch case
the stack is fucked
its either nanoprintf or flantern maybe?
HUH
okay okay
ive made some more progress
syscalls can kinda work
but they then crash horridly
and the original error before it fully died from seriel is as here
FREE WILL IS A FLAW
General Protection Fault
General Registers:
RAX=0x0000000000000000 RBX=0x000000000000000b
RCX=0x00000000a0000000 RDX=0x000000000000002b
RSI=0x0000000000000001 RDI=0x0000000000000000
RBP=0x000000000000006c RSP=0xffff810000020998
R8 =0x00000000004ac200 R9 =0x0000000000000008
R10=0x0000000000000029 R11=0x000000000000002e
R12=0x0000000000000024 R13=0x00000000004ac210
R14=0x00000000a0035c00 R15=0x000000000000d200
Interrupt Frame:
IP=0xffffffff8000c4aa SP=0xffff810000020998
SS=0x0000000000000010 CS=0x0000000000000008
FLAGS : 00000000 00000001 00000000 10000010
Control Registers:
CR0: 10000000 00000001 00000000 00010001
CR4: 00000000 00000000 00000010 00100000
CR8: 00000000 00000000 00000000 00000000
CR2=0x0000000000000000 CR3=0x0000000001d94000
Misc:
ERROR : 00000000 00000001 00000000 00100000
RFLAGS: 00000000 00000001 00000000 10000010
GDTR Base=0xffffffff80016340 GDTR Limit=0x0000003f
IDTR Base=0xffffffff800193a0 IDTR Limit=0x00000fff
LDT=00000000 TR=00000030
the STAR MSR was being set wrong
which did some funky things
because i forgot one < 
im unsure on SFMASK
i tried to look at other implementations for a proper mask and i tried some and they did not work. only 0 worked whoch others tell me isnt correct
i also properly told the thing it wold have RCX and R11 clobberd 
aswell this made things a lil more stable
i may push to dev in a bit and keep working on this
but i am a lil confused
the flags are printed as binary btw, i may add proper parsing for this later?
but the user space app manages to survive a few seconds before death
Oops. Undoing that change
fault seems to be coming from here
/home/evalyn/Documents/Programming/C/evalynOS/src/kernel/interupts//src/kernel/interupts/interupts.asm:57
which is the iretq here
pop rcx
pop rbx
pop rax
add rsp, 16
iretq
is that the syscall code?
interupts.asm:57
yeah i forgot you are using normal syscalls rn
Something is fucking up shit when it system calls and then comes back to interupt
Also that’s the same IP as when I had the mask be 0
So that seems to delay the inevitable
maybe a race condition?
I wasn’t able to get your scheduler trick to work
But this way shouldddd be fine too
It’s just 
Acting up

calling the schedule function from the int handler can go bad very fast
And making it the int handler also went bad?
The int handler calls the PIT code which calls the secedular which then calls the assembly… which then never pops the things off the stack right?
Meaning stack overflow

But why did this never overflow before like this?
Even with running the kernel for hours?
I've found that it never changed rsp correctly when using interrupts
So i'm making a dedicated handler
is there a way i can track the RSP to check if its doing that to me
maybe it could explain musterious stack coruption?
wana go over again with me how it should be domne?
its an assembly ISR that on trigger passes the current RSP to a C function and then switch to the RSP returned by said function @viral bison?
single step
get gef

and the ni to single step instructions (in asm)
or n for c code
s to step in
and fin to finish the current function
And I assume I have a breakpoint on the syscall handler
hardware break
And is this correct
it should
but remember that if you get the rip inside the int handler, you'll get the code inside the int handler
but if you have a dedicated handler, you get the code from where that int was called
Where would I be using the RIP here?
on the ret / iret
Would this new all assembly one still need to push and pop every register?
Just the normal ones I already do
somthing like this @viral bison ?
pit_isr_schedule:
pushfq
push rbx
push rbp
push r12
push r13
push r14
push r15
mov rdi, rsp
call the_c_function
mov rsp, rax
pop r15
pop r14
pop r13
pop r12
pop rbp
pop rbx
popfq
ret
yeah but removing it before borked shit
cr3? and would the C function do that
just do mov cr3, regs

but i have a C function that handles that with some extra stuff. and cant i only return one thing?
and the return is in rax right
so i changed that
it should be done in asm if you don't want a pagefault
rax and rdx
so how do i return 2 values properly?
return an uint128

@viral bison i dont have a uint128
make it
how
wut
look at how i did it
it's a compiler macro
i dont have that
where
of course
autocomplete wont show it
but it works
fml
@viral bison so like this
return ((__uint128_t)current_thread->pagemap->top_level << 64) | current_thread->krsp;
yes
@viral bison

__uint128_t schedule(uint64_t old_krsp) {
pitInteruptsTriggered++;
if (shouldSchedule) {
struct thread *previous_thread = threads->thread;
threads = threads->next_thread;
struct thread *current_thread = threads->thread;
vmm_switch_to(current_thread->pagemap);
tss.rsp0 = (uint64_t)current_thread->stack_top;
wrmsr(UGSBAS, (uint64_t)current_thread);
previous_thread->krsp = old_krsp;
return ((__uint128_t)current_thread->pagemap->top_level << 64) | current_thread->krsp;
} else {
return ((__uint128_t)kernel_pagemap->top_level << 64) | old_krsp;
}
}
global isr0x20
extern schedule
isr0x20:
pushfq
push rbx
push rbp
push r12
push r13
push r14
push r15
mov rdi, rsp
call schedule
mov rsp, rax
mov cr3, rdx
pop r15
pop r14
pop r13
pop r12
pop rbp
pop rbx
; send EOI
push rax
mov al, 0x20
out 0x20, al
pop rax
iretq
where is it going to 0x0 
how are you steting the initial stack?
leme check
*--stack = (uint64_t)task_quit;
*--stack = (uint64_t)entry_point;
*--stack = 0x202;
*--stack = 0;
*--stack = 0;
*--stack = 0;
*--stack = 0;
*--stack = 0;
*--stack = 0;
wait wha
fuk
so do i want ret?
BRUH
what did i do ðŸ˜
look at how i set them
i thought i did 
and i told you to add them before entry point
FUCK
also, flags are not needed (pushfq and popfq)
bc the interrupt does it all for you
and iret restores the flags
so this 
in my case the flags are 0x292
wrong values
dont i do this in assembly?
yes?
what do i need to put there 
*--stack=0x10;
*--stack=rsp;
*--stack=0x292 (or your rflags);
*--stack=0x08;
*--stack=rip;
the kernel thread stack
;-;
i think you save the thread rsp, no?
fuk
im dum
whyyyy
wait
i need to offset that
right
dosnt help 
10 11 or 12 breaks
ehm
don't shift maybe?
just put stack top
the values will be popped anyway when iret reaches that rsp
Here
Yes
find where it crashes then
return ((__uint128_t)kernel_pagemap->top_level << 64) | old_krsp;
shit
thats not valid
huh?
the PIT is setup before the vmm
?
@viral bison update this will not cause a crash
but it locks up all interupts??
global isr0x20
extern schedule
extern shouldSchedule
extern pitInteruptsTriggered
isr0x20:
add dword [rel pitInteruptsTriggered], 1
push rax
mov rax, [rel shouldSchedule]
cmp rax, 1
pop rax
je do_schedule
jne dont_schedule
do_schedule:
push rbx
push rbp
push r12
push r13
push r14
push r15
mov rdi, rsp
call schedule
mov rsp, rax
mov cr3, rdx
pop r15
pop r14
pop r13
pop r12
pop rbp
pop rbx
; send EOI
push rax
mov al, 0x20
out 0x20, al
pop rax
push 0x10
push [rdi]
push 0x292
push 0x08
push rsi
dont_schedule:
sti
iretq
even just this will?????
isr0x20:
add dword [rel pitInteruptsTriggered], 1
push rax
mov al, 0x20
out 0x20, al
pop rax
sti
iretq
yeah @viral bison im never gonna get your way to work.
even making my normal PIT isr in assemblu without the new functon is still fucked
okay i think im getting somwhere. where do i get the RIP in the ISR?
it's the first item in the stack
so from here what should i be doing?
pop that into a register?
i told you to not push flags
FUCK
it won't do anything really
it's just an useless push / pop
these here are completely wrong
they shouldn't be here
then why did ytou tell me to put thoes there before
this is your stack init
i thought this was part of the isr ;-;
f
whats the proper values?
you have to remove those 5 pushes in the isr
k, good
it dosnt crash but it locks up
do i need a sti?
no
it dosnt fix it

it seems to not be scheduling @viral bison??
but if i add a second thread it kinda goes but it page faults
bruh
and its only because its two of the same
otherwise still halts?
im sorry
what did i fuck up this time im so sorry
@viral bison somehow somewhere interupts get disabled 
forever?
yes
oof
even this wont fix it
whyyyyy
the EOI is right here too
I genuinely don’t know what the fuck to do anymore
I’m fucking cursed
@viral bison is this correct too or am i being dumb??
should be
so any ideas?
fwiw I wouldn't tie scheduling to interrupts, it just ends up being messy
if you are doing the same thing as what diamondmaster did that is
how do you schedule via lapic then?
you just call sched() in your timer handler
i mean thats what @viral bison said for me to do
i used to have the PIT ISR call schedule()
but aparently that caused issues
timer handler is an isr tho
acording to diamond
yes?
bc the lapic sends interrupts
uint128?
ye
what I mean is that imo its cleaner if its a normal function you can just call anywhere to switch between threads
and then resume at that exact same point later on
oh, i have a function that calls the interrupt, lol
why not a struct
i had problems with structs
sysv abi to assembly
utint128 splits the two halfs into registers
the compiler would still split the return value into rax and rdx
// void sched_switch_thread(uintptr_t* old_sp_loc, uintptr_t new_sp)
sched_switch_thread:
push rbx
push rbp
push r12
push r13
push r14
push r15
mov [rdi], rsp
mov rsp, rsi
pop r15
pop r14
pop r13
pop r12
pop rbp
pop rbx
ret
tho if this is called from an isr, it will then go back and finish that isr, potentially messing things up
void sched() {
// choose next_thread, update msrs and load page map etc
// switch to there
sched_switch_thread(¤t_thread->sp, new_thread->sp);
}
yeah i had this before
removing pushfq broke things though
thread_switch:
pushfq
push rbx
push rbp
push r12
push r13
push r14
push r15
mov [rdi], rsp
mov rsp, rsi
pop r15
pop r14
pop r13
pop r12
pop rbp
pop rbx
popfq
ret
had this too
it doesn't mess anything up, it returns to the end of the isr where the full regs saved to the irq stack are restored + iret is done to return to wherever the preemption irq was triggered
yikes
it was only because you had the initializers
oh
so i should undo all this mess and go back to where i was when it worked but still broken syscalls?
idk, or you could try fixing it somehow
i'm trying to fix mine too
compiler extensions like uint128 aren't really a good workaround
somehow the stack gets fucked up if i don't put a print on the function XD
if a simple 16 bytes struct (which complies the same way as a 128bit integer) causes problems there's a deeper problem
but if the problem was caused just by initializers then it would be a good idea to go back to that implementation
i mean i liked the other way with the PIT timer calling the schedule
and that worked
but syscall is still fucked
but ive had some minor fixes and progress
is it related to the sched stuff though or is it unrelated
do you switch to rsp0 and/or a dedicated thread kernel stack
it's a common mistake
it can run a few times. and then borks. and if i change SFMASK to zero from ~0x2 it ran for a few seconds somtimes
and i dont think so
should be the mov rsp, [gs:24] part
so you're using a thread kernel stack
nope, it's good, saves you from lots of troubles
like stacks being overwritten when a syscall handler yields and another thread requests a syscall
yes
so what is going on with it 
pretty sure it is setup right
and my gdt is as such
its what @viral bison told me i needed 
compability mode?
ye
i dont do compat mode but aparently its needed to be that format for STAR?
you could skip it
and change that value to the one before the user data 64
tho you have to then be careful to not call syscall from 32 bit mode
what????? thats the same as it is now
won't star (0x18 << 48) be wrong?
i copied it from diamond
it needs to be coherent with gdt segments
documentation on this is so ass for syscall/sysret
what gdt segments is it meant to be
the 48 bits shifted value must be the segment offset for 64bit user code
which should come 8 bytes after the 64 bit user data segment
(iirc)
then why do some syscalls manage to work before failing i womder
the value at star 63:48 should point to the user code32 gdt entry if you have that (and your gdt is of the form user code32, user data, user code64)
yes thats how mine is set?
won't SS become 0x10 kernel data?
isn't SS = CS - 8
I clearly remember having to reorder the segments because of it
yeah its cs - 8 but star 63:48 doesn't point to cs64
if you write 0x18 to star then user cs is at 0x18 + 16 (0x28) and user ss will be 0x18 + 8 (0x20)
but anyway it should be correct yeah
So then what else is causing issues?
I can try to take a look at it if I can get it triggered again lol
This is where I was talking about previous crashes related to the syscall issue
I’m gonna put that all together into a proper commit and push to dev and remove this pit scheduler nonsense
Get what triggered again if I may ask?
some random page fault when running the badapple cmd a bunch of times, is this different from that now?
If too many system calls run it faults
This was fixed and if using int 0x69 they work
And I can spawn it as many as I want
That’s on main branch
But the dev branch is trying to get syscall to work but it’s broken
I tried adding more fixes and had some progress
But did not fully work and then I spent all day trying to get @viral bison s idea to work
Why did you wrap the typedefs into extern C?
i had some functions in there
and later got rid of them
Oh
and never removed extern "C"
project is now on codeberg.
may still commit to github but probally not
https://codeberg.org/EvalynGoemer/evalynOS