problem linking kernel

[yemista]

I have a strange problem when linking my kernel. Functions calls get screwed up. Here is the main kernel code

Code: Select all

void initialize() {
  //  loadGDT();
  cli();
  init_IDT();
  init_interrupts();
  init_pic(0x20, 0x28);
  sti();

  while(1) ;
}

The call to cli() works and returns fine. cli() is declared in an assembly file as global and as extern in a header file that this file includes.

Here is the code for init_IDT()

Code: Select all

void init_IDT() {
	idtr.size = sizeof(IDT_entry) * MAX_INTERRUPTS;
	idtr.offset = &idt;
	load_IDT(&idtr);
}

It works up until the load_IDT call. Here is the bochs output when it reaches that point:

Code: Select all

Next at t=157124767
(0) [0xfffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0

For some reason, its compiling that instruction as a jmp far instead of a call. load_IDT has been coded in assembly the same way as cli, but for some reason wont work while cli does.

[Firestryke31]

Actually, what seems to be happening is that the CPU is resetting. Look at the instruction's address, and you'll notice it's at f000:fff0 which is the first instruction the CPU runs when it starts. Typically the CPU resets when there's a triple fault. It goes like this:

1st fault (caused by anything) -> 1st fault handler -> (look up IDT, sees that the fault handler is invalid) -> double fault -> (same thing) -> triple fault -> reset

I'm guessing there's a mistake in the load_IDT instruction. Are you sure that the function is being called?

[yemista]

It just happens to be called size in my program

Here is the gcc generated code for init_IDT:

Code: Select all

init_IDT:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$8, %esp
	movw	$2048, idtr
	movl	$idt, %eax
	movl	%eax, idtr+4
	movl	$idtr, (%esp)
	call	load_IDT
	leave
	ret

Its failing right before the call, which is showing up in bochs as a jmp far.

[yemista]

its inappropriate to say things like that on presidents day

[Combuster]

its inappropriate to say things like that on presidents day

It is inappropriate to attack people for no reason.

As Berkus said, your code is off. Go fix it instead of whining to us.

[yemista]

so what kinds of things should you post about? Ive been looking at this for 2 weeks

[neon]

I am assuming your code is triple faulting? Use the bochs crash log and have your compiler generate a linker map. Use these as debugging aids.

As Firestryke31 said, bochs is not showing it as a "jmp far". Its showing it do to a triple fault (notice the address of the instruction is in the bios, not your code.) Information on what caused the triple fault may be in your bochs crash log. If you can post that for us (Not the entire log, of course) that would help out

Also, "its inappropriate to say things like that on presidents day" is simply rude, specifically because no one in this thread has said anything "inappropriate" of any nature. I would like to help; so long as there is no more rudeness involved.

[yemista]

Well Im sorry but I felt I was being attacked. Ill look through the crash log. I dont mean to have everyone here do all my work for me. Ive been trying to debug as far as I can before resorting to the boards, but I wouldve never known that jmp far actually indicated a triple fault. I will look through the logs. Thank you

[xenos]

Maybe it would be helpful to see your code for load_IDT, since this seems to be triple faulting. Probably you are trying to load an invalid IDT pointer.

BTW, how do you declare the idtr struct? size should be of type short, offset should be of type long and the struct should have __attribute__ ((packed)) in order to avoid padding bytes that mess up the IDT pointer.

[yemista]

I actually fixed the problem now. There were a lot of things wrong, including have a stack segment setup incorrectly so that permissions did not allow writing to the stack, idt not pointing correctly, idt structures not being packed, but I managed to find them all by figuring out what caused the triple fault. I just had no idea what a triple fault looked like. Thank you for your help