Interrupt handlers corrupting stack?

[Combuster]

objdump the kernel binary, not the object files.

[sortie]

Did you forget to link the executable? You won't get much use out of objdumping an .o file if you are comparing with a linked executable.

Edit: Yeah, what Combuster said.

[ScropTheOSAdventurer]

I feel so stupid right now. Sorry I wasted your time.

[ScropTheOSAdventurer]

Ok, I have found the addresses. Here is 10090c:

Code: Select all

001008f8 <pic_get_irq_reg>:
  1008f8:       53                      push   %ebx
  1008f9:       83 ec 18                sub    $0x18,%esp
  1008fc:       0f b6 5c 24 20          movzbl 0x20(%esp),%ebx
  100901:       89 5c 24 04             mov    %ebx,0x4(%esp)
  100905:       c7 04 24 20 00 00 00    movl   $0x20,(%esp)
  10090c:       e8 63 fb ff ff          call   100474 <outb>
  100911:       89 5c 24 04             mov    %ebx,0x4(%esp)
  100915:       c7 04 24 a0 00 00 00    movl   $0xa0,(%esp)
  10091c:       e8 53 fb ff ff          call   100474 <outb>
  100921:       c7 04 24 a0 00 00 00    movl   $0xa0,(%esp)
  100928:       e8 53 fb ff ff          call   100480 <inb>
  10092d:       88 c3                   mov    %al,%bl
  10092f:       c7 04 24 20 00 00 00    movl   $0x20,(%esp)
  100936:       e8 45 fb ff ff          call   100480 <inb>
  10093b:       89 da                   mov    %ebx,%edx
  10093d:       c1 e2 08                shl    $0x8,%edx
  100940:       0f b6 c0                movzbl %al,%eax
  100943:       09 c2                   or     %eax,%edx
  100945:       89 d0                   mov    %edx,%eax
  100947:       83 c4 18                add    $0x18,%esp
  10094a:       5b                      pop    %ebx
  10094b:       c3                      ret

Here is the C version:

Code: Select all

/* I know the defines should be in the header file, but I threw them into the code section here for the sake of this post. */
#define PIC1_COMMANDPORT 0x20 
#define PIC2_COMMANDPORT 0xA0
uint16_t pic_get_irq_reg(uint8_t combyte) { 
	outb(PIC1_COMMANDPORT, combyte); 
	outb(PIC2_COMMANDPORT, combyte); 
	return (inb(PIC2_COMMANDPORT) << 8) | inb(PIC1_COMMANDPORT); 
}; 

Here is outb:

Code: Select all

00100474 <outb>:
  100474:       8b 44 24 08             mov    0x8(%esp),%eax 
  100478:       8b 54 24 04             mov    0x4(%esp),%edx
  10047c:       ee                      out    %al,(%dx)
  10047d:       c3                      ret
  10047e:       66 90                   xchg   %ax,%ax

Now, here is outb as I implemented it:

Code: Select all

inline void outb(uint16_t port, uint8_t theval) { 
	asm volatile("outb %0, %1" : : "a"(theval), "Nd"(port)); 
}; 

I'll keep debugging.

[dozniak]

Doesn't look like outb is ever inlined.

[ScropTheOSAdventurer]

I forgot to mention this, but the only time the pic_get_irq_reg function is ever used in my interrupt handlers is in the C central handler, when I check to see if it is a spurious interrupt:

Code: Select all

/* struct included for clarity */
typedef struct InterruptData { 
	uint32_t interruptnumber;
	uint32_t gs; 
	uint32_t fs; 
	uint32_t es; 
	uint32_t ds; 
	uint32_t edi; 
	uint32_t esi;  
	uint32_t ebp2; 
	uint32_t esp; 
	uint32_t ebp; 
	uint32_t ebx; 
	uint32_t edx; 
	uint32_t ecx; 
	uint32_t eax;
   uint32_t eip, cs, eflags, useresp, ss;  
	uint32_t errorcode;
} InterruptData;

  void generalinterrupthandler(InterruptData data) { 
	uint32_t num = (uint32_t)data.interruptnumber;
	if (((pic_get_isr() & (1 << num)) >> num)) {   /* Check to make sure it isn't a spurious interrupt */
		if (interrupthandlers[num]) { 
			interrupthandlers[num](); 
		}; 
		pic_sendEOI(num);
	}
	else { 
		if (num > 7) { 
			pic_sendEOI(0); 
		}; 
	}; 
}; 	

[sortie]

Code: Select all

void generalinterrupthandler(InterruptData data)

Is data meant to be a pointer here such that the C function can reliably edit the registers?

[ScropTheOSAdventurer]

Not at all. It is given to the C handler so the function knows the state of the processor immediately before it is called is known; so it can be used by the functions the C handler calls to select options . So if a specific software interrupt handler wants to know the state of EAX so it can select a specific feature to be used, it can just look at the state of EAX through the struct. If you look at my source I haven't implemented this yet in my C handler, but I am planning to do so later. It is also a method of saving the processor state so it can be restored later. It is not meant to be modified at all.

[ScropTheOSAdventurer]

Well, it turns out my OS was so messed up in SO many ways, so I decided to rewrite it. Being EXTRA careful this time, I got interrupts online, keyboard online, so I am basically back to where I was, so everything is looking good! Thank you all for your help