acccidiccc wrote:
so your function does
Code:
.global load_idt
.type load_idt,@function
load_idt:
addq $-16, %rsp # remove 16 from stack register, so you can do stuff as 8(%rsp). presumably
decq %rsi #decrease source register. to underflow it?
movq %rdi, 8(%rsp) #move the IDT pointer to rdi
movw %si, 6(%rsp) #move the len? to the index register
lidtq 6(%rsp) #load the idt with the limit with the limit first
addq $16, %rsp # add the 16 back to the rsp
retq #return
.size load_idt,.-load_idt #get the size. i have no idea why what i found was to set the function size
thanks for your reply! this hopefully can help me. but couldn't you have loaded the idt directly. Not very experienced when it comes to assembly
the si is for indexing, the rsi and rdi for copying, as far as i read. why use them?
EDIT the rsi and rdi are for the ABI right?
Yeah, the comment i put above the function was important. That's how the function is defined in C. I decided to take the pointer in RDI (first argument) and the length in RSI (second argument). However, the size must be below 65536 for architectural reasons, so I can just refer to SI instead of RSI, it means the same thing.
And no, the decrement is not to underflow it. It is just because the first word of the IDTR does not contain the length, but the limit. Which in practice always one less than the length in bytes. The objective is to construct an area in memory that is 10 bytes long, in which the first 2 bytes consist of the limit and the remaining 8 bytes consist of the pointer. I think you read the moves the wrong way around: In AT&T syntax, "movq %rdi, 8(%rsp)" moves the contents of RDI to [RSP+8].
You can, in theory, do the same thing in C like this:
Code:
uint16_t idtr[5] = { len - 1, addr, addr >> 16, addr >> 32, addr >> 48};
asm("lidt %0" : "m"(idtr));
However, I have no idea what the right clobbers and the right specifiers are.
acccidiccc wrote:
... but, it hangs at the lidt instruction for no apparent reason
OK, that is weird. LIDT should either succeed or cause an exception. I can only presume you have managed to trigger a bug. Exception 13 is still #GP, and the manual says that happens when the address is non-canonical. Given you already f*ed up the 32-bit/64-bit thing once, is it possible you are only copying 32 bits of the address into the IDTR?