OSDev.org

Octocontrabass wrote:According to the error code, your IDT entry for interrupt 6, #UD, is invalid. Did you install a handler for #UD?

Octocontrabass wrote:CS and EIP are saved on the stack, the same way as every other exception and interrupt.

It's a good idea to define a struct for the stack frame, then pass a pointer to the top of the stack to your exception handler. That way, you can access anything you need in order to troubleshoot an exception when it happens.

invalid_opcode:
  cli
  ;save all 32bit registers
  pushad
  push dword [esp + 32] ;push eip
  push word [esp + 48] ;push cs
  call invalid_opcode_handler
  pop dword [esp + 48] ;pop cs
  pop word [esp + 32] ;pop eip
  ;return all 32bit registers
  popad
  sti
  iretd

extern void invalid_opcode_handler(uint16_t cs, uint32_t eip);

mrjbom wrote: I tried debugging task_switch(), the problem occurs after "ret", perhaps the control is passed to the wrong place...

iansjack wrote:

mrjbom wrote: I tried debugging task_switch(), the problem occurs after "ret", perhaps the control is passed to the wrong place...

If you've debugged correctly, single-stepping through the code in a debugger, there should be no "perhaps" about the source of the error. It should be immediately obvious if control is returning to the wrong address, and inspection of the stack as you proceed through the switch should make the cause clear.

mrjbom wrote:

iansjack wrote:

mrjbom wrote: I tried debugging task_switch(), the problem occurs after "ret", perhaps the control is passed to the wrong place...

If you've debugged correctly, single-stepping through the code in a debugger, there should be no "perhaps" about the source of the error. It should be immediately obvious if control is returning to the wrong address, and inspection of the stack as you proceed through the switch should make the cause clear.

I found the reason for the error.
The fault was "__attribute__((packed))" which I used in structures... Most likely, the esp was just not where I expected and esp was loading something else.
Thanks for the answer.

iansjack wrote:You are correct that packing the structs was causing the error, but do you understand why? You will often find that you have to pack structs, so if you don't understand what the problem is here then you are setting yourself up for future problems.

The real error was not that you packed the structs but that you miscalculated the offsets. You might also want to reconsider the order of the fields in some of your structs so that it doesn't matter whether they are packed or not. And packing applies more widely than just structs. You can save a lot of memory by thinking about the order of structs and variable declarations.

Octacone wrote: I don't think your problem is fixed. I think it is just masked.
I always use __attribute__((packed) for all of my structures, so GCC doesn't waste space on padding.
Be careful, sometimes you'll spend days bug hunting a non-existant bug, just to figure out that your data is invalid because GCC added padding and you didn't compensate for it.

mrjbom wrote:

Code: Select all

  pop dword [esp + 48] ;pop cs
  pop word [esp + 32] ;pop eip

Octocontrabass wrote:

mrjbom wrote:

Code: Select all

  pop dword [esp + 48] ;pop cs
  pop word [esp + 32] ;pop eip

Functions clobber the arguments you push onto the stack. Use "add esp, 8" or "pop eax; pop eax" to clean up the stack after the function call.

mrjbom wrote: If I can't push parameters to pass them to the C function...?

iansjack wrote:

mrjbom wrote: If I can't push parameters to pass them to the C function...?

That's not what was said. You do pass parameters via the stack (in 32-bit mode), but this means you have to clean up the stack when you exit the function.