tried out new idt set up but this happened!!!

[ITchimp]

I was told that the cpu will push the following onto stack for interrupt handling the following
in that order

Code: Select all

u32int eip, cs, eflags, useresp,

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???

[Octacone]

IIRC, those two are user mode values which means they will contain trash in kernel mode.

[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....

[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.

[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?

[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.

[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!!!'

[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.

[ITchimp]

I think this forum needs a healthy dose of energy injection...

[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

Code: Select all

add 8, %esp

produces the following assembly routine (it is a bit weird)

Code: Select all

add esp, dword ptr ds:0x8

but the test code of the tutorial I am following, which behaves correctly

produces a slight different assembly:

Code: Select all

add esp, 0x00000008

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?

[Octocontrabass]

You already asked that question and got the answer.

[iansjack]

Learn the particular.assembler syntax that you are using.