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

ITchimp · **Joined:** Sat Aug 18, 2018 8:44 pm **Posts:** 127

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

Code:

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 · **Joined:** Fri Aug 07, 2015 6:13 am **Posts:** 1134

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

ITchimp · **Joined:** Sat Aug 18, 2018 8:44 pm **Posts:** 127

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 · **Posted:** Fri Jun 05, 2020 3:36 am

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 · **Joined:** Sat Aug 18, 2018 8:44 pm **Posts:** 127

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 · **Posted:** Fri Jun 05, 2020 4:44 am

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 · **Joined:** Mon Jan 15, 2018 2:27 pm **Posts:** 201

This thread subject sounds (reads?) just as these shady scam ads :lol:

Like 'You won't believe…' or 'Doctors hate this guy for…' or 'Tried out new IDT set up but this happened!!!'

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 1604

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 · **Joined:** Sat Aug 18, 2018 8:44 pm **Posts:** 127

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

ITchimp · **Joined:** Sat Aug 18, 2018 8:44 pm **Posts:** 127

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:

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:

add 8, %esp

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

Code:

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:

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 · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5143

You already asked that question and got the answer.

iansjack · **Posted:** Fri Jun 05, 2020 11:37 pm

Learn the particular.assembler syntax that you are using.

OSDev.org

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

Who is online