OSDev.org

As said previously:

So a far jump won't work. Still working on that part.

UPDATE: Not sure if this would work or not, but potentially:
might

UPDATE 2: Nope, it just barfs this:

then triple faults.

It's time to install and debug your exception handlers. I'd start by getting rid of the unnecessary duplicate RSP in this struct, and then fix this assembly to match the struct, pass a pointer to the struct, align the stack correctly, and clear the direction flag. (Most of those changes are to satisfy the System V ABI.)

Oh, and get rid of CLI. If you want interrupts disabled upon entry to your ISR, install interrupt gates in your IDT.


As with IRETQ, you need to write RETFQ to get the 64-bit instruction (or LRETQ if your assembler is picky about following AT&T syntax). Also, when the operand is 0, you can remove it to make your code smaller without changing its behavior.

To be clear, the "unnecessary" RSP is the one on the line you highlighted, not the "userRsp" below, right?

Yes. It's one of several mistakes you copied from a tutorial. (Since there's no PUSHA/POPA in 64-bit mode, you don't even need a placeholder.)

Yes, I did look at that page (for example, my ISR 17 and 21 do use the pushed error code). I just didn't catch that one.
Also I'm not sure if this push and pop asm looks correct or not... https://github.com/techflashYT/Techflash-OS/blob/537f54b8a848c117c6d28d2a3193ca38e79be9ba/kernel/hardware/CPU/interrupts/ISRASM.S#L8 Testing now.

UPDATE: seems to crash at the "retfq":

Well, OK, I forgot about that. Yes, there is no direct far jump in 64-bit mode. But you can make an indirect far jump, or a far return. BTW, that is "lret" in AT&T. I have no idea what "retf" does, but not what you want for sure. In the position you have, I would encode it as this:


Since the number 8 makes an appearance multiple times here: The 8 in the first push is actually the CS selector. In the second push, it is the offset to the return address (which was 0 before the first push). And finally, in the lretq it gives the amount to adjust the stack pointer after removing the far pointer from the stack. After the two pushes, the stack is "<return address> - 8 - <return address>", and you need to clear that all out when returning. A normal lretq without operand would leave the old return address on stack, so increase the stack pointer by another 8 before returning. Thank god I used to write assembler programs for Windows, which is how I knew of the version of return with immediate operand.

You can of course also do something like
But that is longer and doesn't return from the function, so you need to add that as well. Ultimately your call.

According to before, retf is just unnofficial syntax for lret.

UPDATE: It KINDA works now!
Less errors!

Btw it's almost 1am for me I gtg. I'll read anything anyone responds with tomorrow.
UPDATE: Back. Still no idea what that error is.

It doesn't match your struct. On x86, the stack grows down, so you need to push the last element first.

You're also not passing a pointer to the struct, not clearing the direction flag, not using your POPALL macro, and not adjusting the stack pointer to remove the interrupt number and error code before IRETQ.


Did you push appropriate values onto the stack for it to pop?

Alright, I did most of those now, except pass a pointer to the struct (pointers in asm are even more confusing than in C, this might take some time for me to figure out)
The changes are live now on GitHub if you want to see what I did.

UPDATE: Ok this is even more confusing than I thought. How would I get the address of the "struct" that we fill out using that PUSHALL macro? Would I just push the current address of the stack pointer before the macro?

Here's a hint: the instruction you want is "mov $rsp, $rdi".


Why did you set the direction flag right before IRETQ? It's just going to pop RFLAGS from the stack anyway, so it doesn't matter what the direction flag is at that point.

Alright, I fixed it, testing it now.

Yes. What's wrong with that instruction? It copies the stack pointer into RDI, then ISRHandler uses that pointer to view the stuff in the struct. I already reversed the order of the PUSHALL and POPALL macros to match the fact that the stack grows downwards.

Also, after updating the function to actually treat the argument as a pointer:

RSP is the stack pointer. It changes as you push and pop things from the stack.

When will it point to the first element of the struct?

Wait now I'm confused. Yes I understand RSP stands for "Register Stack Pointer", and I get that it changes. But now my brain hurts, doesn't it always (without directly modifying it with something like add or sub), point to the next byte of the stack? Or does it always point to the last pushed item? Hang on, let me try putting the mov instruction into the macro quick, after the first push. And I'll see what happens.

UPDATE: After testing it out with that method:

So it gives a different error this time, but still an error. It seems like it happens at the "iretq" instruction. Something about the segment registers. Not sure what the "RPL" means in this case.
UPDATE 2: Also tried it at the end of the macro too, almost same thing happens. This time it's one "access_read_linear(): canonical failure" and 55 of the "iret64: SS.rpl != CS.rpl"