Page 1 of 1
tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 2:59 am
by ITchimp
I was told that the cpu will push the following onto stack for interrupt handling the following
in that order
ss
but when I print out those values one by one
I found that ss in not 0x10, it is actually similar to useresp, which is a stack value,,
what is going on???
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 3:04 am
by Octacone
IIRC, those two are user mode values which means they will contain trash in kernel mode.
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 3:24 am
by ITchimp
how does then iret deal with them? what should I do? what is the recourse?
also there is eflags that is also on the stack....
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 3:36 am
by iansjack
Simple - there's something wrong with your print routine. It looks like you are starting at the wrong position on the stack. Presumably you are looking at an interrupt whilst running in user mode?
Run your code under a debugger, set a break point in the interrupt handler, and look at the stack.
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 4:25 am
by ITchimp
I am running everything in bochs.... don't know how to run the debugging mode...
but I am however aware of xchg %bx, %bx hack, it was not always usefull. but I am trying...
how to run hte kernel in debugger like what you said?
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 4:44 am
by iansjack
https://wiki.osdev.org/Kernel_Debugging
Learn how to use a debugger - it will serve you well when you get to the difficult stuff.
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 8:26 am
by pvc
This thread subject sounds (reads?) just as these shady scam ads
Like 'You won't believe…' or 'Doctors hate this guy for…' or 'Tried out new IDT set up but this happened!!!'
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 11:56 am
by nullplan
In 32-bit mode, SS and ESP are only pushed to the stack if a change of privilege level occurred. So if CS indicates ring 0 then ESP and SS are invalid values.
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 5:51 pm
by ITchimp
I think this forum needs a healthy dose of energy injection...
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 6:42 pm
by ITchimp
first I bow to all the OS gods and immortals!!!
I have yet another problem that I just discovered...
context, I am running in kernel mode so there is no priviledge change...
the problem I have is that the code returning from ISR corrupts the stack
the magic_break option is enabled so "xchg %bs, %bs;" will generate a break point
the ISR common stub is the following, it is as standard as it gets
first I bow to all the OS gods and immortals!!!
I have yet another problem that I just discovered...
context, I am running in kernel mode so there is no priviledge change...
the problem I have is that the code returning from ISR
Code: Select all
isr_common_stub:
pusha
mov %ds, %ax
push %eax
mov $10, %ax
mov %ax, %ds
mov %ax, %es
mov %ax, %fs
mov %ax, %gs
call isr_handler
pop %ebx
mov %bx, %ds
mov %bx, %es
mov %bx, %fs
mov %ax, %gs
popa
add 8, %esp
sti
iret
on bochs debugging prompt, I notice that
produces the following assembly routine (it is a bit weird)
but the test code of the tutorial I am following, which behaves correctly
produces a slight different assembly:
so the net result is that the test code behaves correct. my own code corrupts the stack... I am wondering why the same isr_common_stub generates different code?
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 7:25 pm
by Octocontrabass
Re: tried out new idt set up but this happened!!!
Posted: Fri Jun 05, 2020 11:37 pm
by iansjack
Learn the particular.assembler syntax that you are using.