Error in tutorial?

[Cjmovie]

Is the code for the structure here:
http://osdever.net/bkerndev/Docs/isrs.htm

the 'regs' structure, that is. It seems reverse to what it should be by the order of pushing. Not completly reverse, but each line seperately needs reversing?

Or is it just that I haven't slept in 27 hours?

[AR]

Not sure about the PUSHA line, the 3rd looks fine, the 4th I can't remember the stack layout for but I think it's ok, the first line is backwards.

[Pype.Clicker]

Code: Select all

mov eax, _fault_handler
    call eax       ; A special call, preserves the 'eip' register

sure looks funny...

on my side, i do have

Code: Select all

typedef struct excCpuState{
  dword es,ds,fs,gs,ss;
  dword edi,esi,ebp,esp,ebx,edx,ecx,eax;
  dword number,errcode;
  dword eip,cs,flags;
} excCpuState;

processException:
        pushad
        mov ebp,esp
        ...
        mpush ss,gs,fs,ds,es
        ...
        push ebp
        call _processExcList
        add esp,4
        ...

so i'd rather say that the 'segments order' in the tutorial is wrong.

[Cjmovie]

This will probably show my ignorance to a lot of ASM, but what is 'mpush' or 'pushad'?

I'm having a little trouble following that code.

Oh yeah, and the mis-order might explain why my code segment is 0x1126......

[Pype.Clicker]

pushad is a NASM stuff for saying "PUSHA and make it 32bits whatever bits xx are there"

"mpush xx,yy,zz" is just a macro for "push xx ; push yy ; push zz" ...

.../kernel/src/head/asm/enhance.ash

Code: Select all

%macro mpush 1-*
%rep %0
        push %1
%rotate 1
%endrep
%endmacro

[Cjmovie]

....Nope, still confused

What's in between the '...' pretty dots?

[Pype.Clicker]

plenty of things that have nothing to do with the stuff we're talking about:

check out the CVS if you're really willing to find out ...

[Cjmovie]

Actually, I was hoping for more detail on push and pop's in between...

Hmm...What about this tut:

With the help of this table, we can see that setting a stack at 090000h can be a good idea for now. It's away from our code and it's large enough for now (0FFFFh). We'll not be needing the stack in this tutorial, but it's always nice to learn to do things right from the beginning.

As found at http://osdever.net/tutorials/brunmar/tutorial_02.php

It sounds like he's saying start the stack at 90000h and it grows up...but the stack grows downward!

All this conflicting info....uh, head hurts

At least I'm able to stitch these tut's together to FIND these errors before my kernel hides them with REAL exception handlers.....

*edit*
Also, after fixing the above by reversing the top line, why does (when an exception like / by 0 occurs) it say SS is 0? That makes NO sense! I made a seperate function that pushes it on the stack and trys it, it reports fine...IDK.

[Pype.Clicker]

when facing conflicting info, rather refer to authoritative datasheets/manuals. E.g. opcode reference manual in Intel's documentation will tell you "push" actually decreseas ESP and "pop" increases ESP. This is what we mean with "downward-growing stack" ...

And keep in mind that, with the exception of "cs, eip and eflags", what you can read in the "ExcCpuStat" structure depends on what your ISR push'd before. E.g. in Clicker, i purposefully push a fake error code for exception that have no such things so that the higher-level handler can be the same for every handlers, and i also push the exception number manually. If your kernel don't do such things, you'll have nothing but garbage in that portion of the "state" structure.

Similarily, if you don't have "push ss" somewhere, ...

Clicker do following:
- receive eflags, cs, eip on the stack
- push error code if none present
- push exception number
- use "pusha" to get all the generic registers saved
- push manually ss, then gs, then fs, then ds, then es (order is personnal choice but it has implication on the structure)
- capture the current stack pointer in ebp and push that on the stack: it will be used as an argument by the C function (actually, a pointer to all the data we've just pushed) so that the exception handler can gather information about the CPU state, but also can alter the state that will be restored directly.
- call the C exception handler...

[Cjmovie]

receive eflags, cs, eip on the stack

OK, but then why does the tutorial grab (in order, oppositie of stack) eip, cs, eflags, useresp, ss (last two seem extra..)

I REALLY need to read the intel manuals....oh well, off to download them

[Cjmovie]

Woah - I think I just fixed a huge problem. I was (as the tutorial #1 was):

Code: Select all

push byte 0  ;Error dummy

But the pointer referenced it as dword (int), and then at the end to clear it:

Code: Select all

add esp, 8  ;Take Error code and ISR # off stack

Which completly throws off the IRET, causing CS, flags, and eip to be completly TRASHED, causing a lot of trouble.

Further testing shall see.....

[oswizard]

It was right - 'byte' refers to the size of the immediate operand to the instruction. Otherwise, NASM might use a 32-bit immediate value and waste space. It is pushed on the stack as a 32-bit value, in all cases.

The add esp, 8 instruction takes care of the fake error code _and_ the exception number, if I remember the tutorial correctly.

The esp, ss are _only_ pushed if there is a CPL change - a user-level function executing an interrupt instruction. (On x64 machines they are always pushed, but that's a different story...)

If you want the real ss you will have to push it yourself.

Hopefully that cleared up some confusion.
Mike

[oswizard]

Another thing - check the calling convention of _fault_handler - if it pops its arguments off the stack (MSVC: __stdcall) or expects you to pop them (MSVC: __cdecl). If you are using GCC, perhaps Pype or someone else knows the proper syntax.

If it is the equivalent of __cdecl, keep the pop eax right after the call. Otherwise remove it.

Mike

[Pype.Clicker]

under GCC, you're the one to clear the arguments. I'm not aware of anything that could make the callee (yep, that's the word) clear the stack of argument.

Hence the "add esp, 4" after "call _handler" in my code: it dismiss the argument previously pushed and the stack returns to the state it had before you "push ebp". You could have used "pop exx" instead, but since you're not interested in getting back the value, dismissing it is equivalently good (and it will makes you less surprised to see "add esp, 64" when you'll have to dismiss a ton of arguments ...)

About "push byte 0", both push 4 bytes on the stack, but "push byte 0" is 2 bytes long instruction while "push 0" is 5 bytes long ...

(yep, definitely, you should grab the manuals ...)

[Cjmovie]

That's the problem with never reading an ASM book.
I've taught myself all I know about ASM by reading well (sometimes not so....) commented ASM code.

So I end up assuming things that aren't true.
The only time I really 'learned' from a book on ASM was when I wanted to program the SX52 microcontroller.....