OSDev.org

Octocontrabass wrote:That won't work for exceptions. You need to know which IDT entry the CPU used in order to tell which exception occurred.

It might work for IRQs, but it'll be a lot slower than looking up the interrupt number in your registers struct.

Techflash wrote:That just sounds like a major size issue though.

.macro ISR_NOERR num
.align 8
	push $\num-128
	jmp ISRCommonStubNoErr
.align 8
.endm

.macro ISR_ERR num
.align 8
	push $\num-128
	jmp ISRCommonStubErr
.align 8
.endm

.global ISRStubArray

ISRStubArray:

ISR_NOERR 0
ISR_NOERR 1
ISR_NOERR 2
ISR_NOERR 3
ISR_NOERR 4
ISR_NOERR 5
ISR_NOERR 6
ISR_NOERR 7
ISR_ERR   8
ISR_NOERR 9
ISR_ERR   10
ISR_ERR   11
ISR_ERR   12
ISR_ERR   13
ISR_ERR   14
ISR_NOERR 15
ISR_NOERR 16
ISR_ERR   17
ISR_NOERR 18
ISR_NOERR 19
ISR_NOERR 20
ISR_ERR   21
ISR_NOERR 22
ISR_NOERR 23
ISR_NOERR 24
ISR_NOERR 25
ISR_NOERR 26
ISR_NOERR 27
ISR_NOERR 28
ISR_ERR   29
ISR_ERR   30
ISR_NOERR 31

.set i,32
.rept 256-32
ISR_NOERR i
.set i,i+1
.endr

ISRCommonStubNoErr:
    pushq (%rsp) # copy interrupt number to the correct location
ISRCommonStubErr:
    push %r15
    push %r14
    (etc)

Octocontrabass wrote: Instead of using 256 unique symbols for each of the stubs, you can make them all the same size and initialize your IDT with a loop. That should come out smaller overall. Borrowing some excellent ideas from earlier in this thread, I came up with this:

Code: Select all

...

The usual "I haven't actually tested this so no guarantees it's correct" applies. This code is subtracting 128 from the interrupt number before pushing it onto the stack - you'll have to take that into account when you use the interrupt number in your struct.

Also, while I was writing this post, I spotted a typo in your macros: you need a $ prefix on the three push instructions to use an immediate operand instead of a memory operand.

Techflash wrote:1. Why does the code subtract 128 from the interrupt number? Is it needed for the stack alignment?

Techflash wrote:2. I fixed that typo already in the current version (not yet committed) it still seems broken [Although there's no more read memory errors, just the triple fault remains].

Octocontrabass wrote:It's needed to keep all of the stubs under 8 bytes. The PUSH instruction is two bytes long when the immediate value is between -128 and 127, but five bytes long for immediate values outside that range.

Octocontrabass wrote:I haven't gone out of my way to comb through the code looking for mistakes. I'd need more details about the exception to track it down. (This is why exception handlers are important!)

Techflash wrote:3. How would the "ISRStubsArray" not be ended immediately by the first macro? Don't labels in ASM typically end once there is another label definition?

Techflash wrote:4. How would the array be accessed in the C code for the loop that sets the IDT values?

extern const uint64_t ISRStubArray[256];

(...)

    for( int i = 0; i < 256; i++ )
    {
        IDTSetGate(i, &ISRStubArray[i], 0x08, 0x8E);
    }

Techflash wrote:The triple fault wasn't with that code yet. I was just mentioning that fixing that typo alone fixed the errors, but not the triple fault.

Octocontrabass wrote:There isn't another label definition. Even if there were, it wouldn't matter: the label only needs to provide a symbolic name for the address where it appears, I'm not using it for anything that depends on size or scope. (But now that you mention it, I think I forgot an ".align 8" directive before that label.)

Octocontrabass wrote:

Techflash wrote:4. How would the array be accessed in the C code for the loop that sets the IDT values?

Something like this:

Code: Select all

extern const uint64_t ISRStubArray[256];
...
        IDTSetGate(i, &ISRStubArray[i], 0x08, 0x8E);
    }

Octocontrabass wrote:There are still errors if you're getting a triple fault, they just don't appear with your current log settings.

Octocontrabass wrote:You only have 31 out of the 256 ISR stubs in the array. You didn't copy the code to generate the ones above 31, and you have one missing here.

I don't know if that's the problem, though. It's hard to say what's going on with no information about what code caused those exceptions.

Octocontrabass wrote:That log does not include a register dump from the first exception, so I can't tell what's going on. Does Bochs not have anything equivalent to QEMU's "-d int"?

Octocontrabass wrote:Unfortunately, that only tells you that there's eventually a page fault.

You might be able to set a breakpoint on ISRHandler() to see what's up.