Weird IDT bug...

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
suthers
Member
Member
Posts: 672
Joined: Tue Feb 20, 2007 3:00 pm
Location: London UK
Contact:

Weird IDT bug...

Post by suthers »

Ok so I initialize my IDT with this code:

Code: Select all

mov eax, offset1_0
	mov ebx, _isr0
	mov edx, 32
	.isr_setup:
	mov [eax], bx
	add eax, offset2_0 - offset1_0
	mov ecx, ebx
	shr ecx, 16
	mov [eax], cx
	add eax, offset1_1 - offset2_0
	add ebx, _isr1 - _isr0
	dec edx
	jnz .isr_setup
	mov eax, offset1_32
	mov ebx, _irq0
	mov edx, 16
	.irq_setup:
	mov [eax], bx
	add eax, offset2_32 - offset1_32
	mov ecx, ebx
	shr ecx, 16
	mov [eax], cx
	add eax, offset1_32 - offset2_31
	add ebx, _irq1 - _irq0
	dec edx
	jnz .irq_setup
	lidt [idt_pointer]
The offsets refer to the offsets in the idt...
But when I test it I get this in my IDT:

Code: Select all

Interrupt Descriptor Table (base=0x000000000010061e, limit=383)
IDT[0x00]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x01]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x02]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x03]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x04]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x05]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x06]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x07]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x08]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x09]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x0a]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x0b]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x0c]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x0d]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x0e]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x0f]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x10]=32-Bit Interrupt Gate target=0x002a:0x00000000, DPL=0
IDT[0x11]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x12]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x13]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x14]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x15]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x16]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x17]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x18]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x19]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x1a]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x1b]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x1c]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x1d]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x1e]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x1f]=32-Bit Interrupt Gate target=0x0008:0x00000000, DPL=0
IDT[0x20]=32-Bit Interrupt Gate target=0x0008:0x00100203, DPL=0
IDT[0x21]=32-Bit Interrupt Gate target=0x0008:0x0010020a, DPL=0
IDT[0x22]=32-Bit Interrupt Gate target=0x0008:0x00100211, DPL=0
IDT[0x23]=32-Bit Interrupt Gate target=0x0008:0x00100218, DPL=0
IDT[0x24]=32-Bit Interrupt Gate target=0x0008:0x0010021f, DPL=0
IDT[0x25]=32-Bit Interrupt Gate target=0x0008:0x00100226, DPL=0
IDT[0x26]=32-Bit Interrupt Gate target=0x0008:0x0010022d, DPL=0
IDT[0x27]=32-Bit Interrupt Gate target=0x0008:0x00100234, DPL=0
IDT[0x28]=32-Bit Interrupt Gate target=0x0008:0x0010023b, DPL=0
IDT[0x29]=32-Bit Interrupt Gate target=0x0008:0x00100242, DPL=0
IDT[0x2a]=32-Bit Interrupt Gate target=0x0008:0x00100249, DPL=0
IDT[0x2b]=32-Bit Interrupt Gate target=0x0008:0x00100250, DPL=0
IDT[0x2c]=32-Bit Interrupt Gate target=0x0008:0x00100257, DPL=0
IDT[0x2d]=32-Bit Interrupt Gate target=0x0008:0x0010025e, DPL=0
IDT[0x2e]=32-Bit Interrupt Gate target=0x0008:0x00100265, DPL=0
IDT[0x2f]=32-Bit Interrupt Gate target=0x0008:0x0010026c, DPL=0
It doesn't set the first 32 entries and its worse if i remove the rest, it prints all 255... (with completely bogus values).
Any body know what I'm doing wrong?
Thanks in advance,

Jules

P.S. sorry for the incoherent post...

edit: removed accidental add on at the end...
Last edited by suthers on Sat Jun 14, 2008 1:28 pm, edited 1 time in total.
User avatar
suthers
Member
Member
Posts: 672
Joined: Tue Feb 20, 2007 3:00 pm
Location: London UK
Contact:

Post by suthers »

Yah I reallised the first post, was incoherent and I posted it without knowing much about the problem first.
But I've reallised that the problem is far stranger than I thought it was....
Basically, I can't add anything to the main function of the asm caller for my kernel... Its really weird, if I add anything, even just a simple hlt instruction, the kernel prints random symbols on the screen and it messes up the IDT/GDT (though i've noticed that how badly they get messed up is proportional to the size of the instruction I add, for a simple hlt, the GDT isn't effected and the IDT has only a few bogus values added on the end..., whereas for a jmp/call, the whole things are filled with bogus values....)
The weird thing is i've tried to add simple little instructions everywhere in this function and wherever it is, it always causes this bug, but if I add into any other function, even the function directly after it, it doesn't have this effect, leading me to conclude that it's probably a problem during linking...
I really don't know where to start to fix this..., any suggestions?
Thanks in advance,

Jules

P.S. sorry about the last post, it was stupid and I didn't give enough data for anybody to see anything...
User avatar
suthers
Member
Member
Posts: 672
Joined: Tue Feb 20, 2007 3:00 pm
Location: London UK
Contact:

Post by suthers »

Here's the function that causes the problem:

Code: Select all

main:
	mov esp, stack
	mov dl, 0x04
	mov ecx, 0B8280h
	mov esi, kernel_starter_active
	call PutStr_32
	mov edx, 32
	mov eax, _isr0
	mov ebx, offset1_0
	.isr_setup:
	mov ecx, eax
	mov [ebx], cx
	shr ecx, 16
	add ebx, offset2_0 - offset1_0
	mov [ebx], cx
	add ebx, offset1_1 - offset2_0
	add eax, _isr1 - _isr0
	dec edx
	jnz .isr_setup
	lidt [idt_pointer]
	call _kernel_main
	cli
	hlt
Its in the text section.
And just in case my suspicion is correct here's my linker script:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(main)
SECTIONS
{
  .text  0x100000 : {
    *(.text)
    *(.rodata)
  }
  .data  : {
    *(.data)
  }
  .bss  :
  { 					
    *(.bss)
  }
}
Yah it's really simple, so that might be a problem.... (Not all the sections that gcc can generate are accounted for....)
Thanks in advance,

Jules
User avatar
suthers
Member
Member
Posts: 672
Joined: Tue Feb 20, 2007 3:00 pm
Location: London UK
Contact:

Post by suthers »

Is there anything else I should post?
Thanks in advance,

Jules
User avatar
bewing
Member
Member
Posts: 1401
Joined: Wed Feb 07, 2007 1:45 pm
Location: Eugene, OR, US

Post by bewing »

I would think that the main question is: is your base address for your IDT array really at 0x1061e? That seems like a pretty non-sensical number.
If it's not supposed to be at 0x1061e, then it's your idt_pointer structure that's screwed up. This is what seems most likely to me. That you are not initializing idt_pointer, except to some relative address in your codespace.

The second question is: have you already preset the other two words of each IDT correctly (with the segment number -- probably 8, and the permission level -- probably something like 0x8e00)?
User avatar
suthers
Member
Member
Posts: 672
Joined: Tue Feb 20, 2007 3:00 pm
Location: London UK
Contact:

Post by suthers »

The two preset words of the IDT were correctly set to 0x08 and 0x8e00.
And the address given for the different isrs are correct.
And for my IDT pointer I use the standard:

Code: Select all

idt_pointer:
	idt_size dw idt_end - idt - 1
	idt_base dd idt
Everything works if I leave it like it is, but if I add anything, anywhere, I get a messed up IDT and GDT and the print function prints out random garbage... (Yes, this even happens if I add a nop...).
This is a really weird problem, I don't even know where to start...
Anybody know what's wrong?
Thanks in advance,

Jules
thooot
Member
Member
Posts: 30
Joined: Sun Jun 01, 2008 11:20 am

Post by thooot »

Is your kernel a flat binary image or an executable? If its flat binary did you set the origin correctly? If you set the origin to 0 then you you'll have to add the actual offset of the kernel to the idt address. Have you tried copying the IDT table somewhere else in memory and then pointing to that?
User avatar
suthers
Member
Member
Posts: 672
Joined: Tue Feb 20, 2007 3:00 pm
Location: London UK
Contact:

Post by suthers »

Its a flat binary and yes I have put the offset in the linker script...
Thanks in advance,

Jules

edit: Yah i'll try moving the IDT to somewhere... and if I hadn't put a correct offset, I wouldn't even be able to get a print function working let alone a basic working IDT (It does work if I don't change the current code)

second edit: fixed spellings
User avatar
bewing
Member
Member
Posts: 1401
Joined: Wed Feb 07, 2007 1:45 pm
Location: Eugene, OR, US

Post by bewing »

Well, I will at least suggest that you put an align statement before your "idt" label. 0x1061e is NOT aligned properly. Adding a NOP will make it be misaligned even more badly.

I would also be interested in knowing the alignment (value) of offset1_0. I bet it's misaligned, too.
User avatar
suthers
Member
Member
Posts: 672
Joined: Tue Feb 20, 2007 3:00 pm
Location: London UK
Contact:

Post by suthers »

Yah I should of done that at the beginning...
So I added:

Code: Select all

align 4
But that didn't fix it (Though, it did change the characters displayed).
Interestingly, it generated different outputs on bochs 2.0.2 and 2.3.6.
On 2.0.2, it generated meaningless garbage, but in 2.3.6 it outputted what where obviously snippets of the intended output, also the alignment didn't completely fix the table issues...
Thanks in advance,

Jules

edit: spelling fixes
User avatar
suthers
Member
Member
Posts: 672
Joined: Tue Feb 20, 2007 3:00 pm
Location: London UK
Contact:

Re: Weird IDT bug...

Post by suthers »

Fixed, memory management error caused as indicated in my other post...
Thanks,

Jules
Post Reply