[Solved] Paging problem + GPFs

[JamesM]

It means you borked something else.

Are you perchance using an unlinked version of your code? The address of the call instruction is just pointing nowhere

To elaborate on what Combuster said, your call instruction doesn't look like it was linked properly. It should call a function in your kernel, but instead it calls to a bad address.

Did this disassembly come from an object file or your final kernel?

Code: Select all

 118:   e8 fc ff ff ff          call   119 <isr31+0x19>
 11d:   5b                      pop    %ebx

[jnc100]

I must agree with the sentiments of the posts from JamesM and Combuster: an instruction like 'e8 fc ff ff ff' is the way to produce a call in an object file with an addend of -4 assuming you're using ELF with .rel (rather than .rela) linkage.

i.e. use ld on the output

Regards,
John.

edit: I've just noticed you were posting the object file. Suggest you post the disassembly of the final binary instead.

[White-spirit]

It means you borked something else.

Are you perchance using an unlinked version of your code? The address of the call instruction is just pointing nowhere

Do you mean the disassembly code ? Yes that's right .

Okay thanks I'ill post the disassembled binary code ^^"

EDIT : here's the code

Code: Select all

00103228 <isr31>:
  103228:	fa                   	cli    
  103229:	6a 00                	push   $0x0
  10322b:	6a 1f                	push   $0x1f
  10322d:	eb 00                	jmp    10322f <isr31+0x7>
  10322f:	60                   	pusha  
  103230:	66 8c d8             	mov    %ds,%ax
  103233:	50                   	push   %eax
  103234:	66 b8 10 00          	mov    $0x10,%ax
  103238:	8e d8                	mov    %eax,%ds
  10323a:	8e c0                	mov    %eax,%es
  10323c:	8e e0                	mov    %eax,%fs
  10323e:	8e e8                	mov    %eax,%gs
  103240:	e8 6f d7 ff ff       	call   1009b4 <isr_handler>
  103245:	5b                   	pop    %ebx
  103246:	8e db                	mov    %ebx,%ds
  103248:	8e c3                	mov    %ebx,%es
  10324a:	8e e3                	mov    %ebx,%fs
  10324c:	8e eb                	mov    %ebx,%gs
  10324e:	61                   	popa   
  10324f:	83 c4 08             	add    $0x8,%esp
  103252:	fb                   	sti    
  103253:	cf                   	iret   

[JamesM]

OK I'm fed up of this thread going around in circles now.

Please post a tarball of your code, including your Makefiles etc.

[White-spirit]

Okay thanks, I've attached the tarball ( a grub floppy image with the name floppy.img is needed, you also need fasm to compile the sources : http://flatassembler.net/ ) .

Thanks

[JamesM]

Hi,

EDIT2: Post updated to cover the *actual* problem.

I don't see what your problem is. You force a page fault, the page fault occurs, is handled, and of course keeps occurring. No GPFs fire at all.

So what's the problem? "Page fault" is in the "Fault" class of exception - when you IRET control returns to the faulting instruction, not the instruction after as in the "Trap" type.

This is so that your page fault handler can change the page tables to make such an access valid. It is expected that if that cannot be accomplished, the current task be killed (in POSIX, with a SIGSEGV), so control should never actually return to the user program.

All in all there seem to be no problems anywhere - everything is doing as it should do.

Cheers,

James

[White-spirit]

Hello,

thanks for testing the code but I already know that it works on Qemu ( why interrupt 9 and not 8 on your screenshot ? ), but in bochs I get GPFs after IRET when interrupts 8, 10-14 are fired.

For the page faults, I already know that all the faults return to the instruction that caused the fault, to let, for example, the page faults handler set some pages which don't exist in RAM .

EDIT :

here are some screenshots of my kernel runing in bochs .

[JamesM]

Hi,

I assumed that you knew what that problem was. You're manually causing a software interrupt on a vector that assumes an error code is pushed.

The CPU never pushes error codes on software-initiated interrupts (i.e. using the "int 0x8" instruction), no matter what the vector number.

So your stack ends up misaligned and the IRET GPF's. As stated several times before by AJ and others.

Cheers,

James

[White-spirit]

Thank you, and what about the GPFs after the page fault in Bochs ?

[AJ]

That's because of the stack misalignment. Your IRET instruction will be attempting to load your error code as if it were a code segment selector...

Cheers,
Adam

[JamesM]

That's because of the stack misalignment. Your IRET instruction will be attempting to load your error code as if it were a code segment selector...

Cheers,
Adam

Not quite - it's an *actual* page fault he does.

Interesting how it works in qemu but not in bochs. When I test it in bochs I get the read_virtual_checks(): read beyond limit errors and a GPF firing.

After investigation I've worked out that that error is caused by your read - you're reading a 4-byte value (u32int) from 0xFFFFFFFF. The emulator doesn't support wraparound properly so it gives an error message of its own and a general protection fault.

Reading from 0xFFFFFFF0 instead causes no such problems.

Cheers,

James

[AJ]

After investigation I've worked out that that error is caused by your read - you're reading a 4-byte value (u32int) from 0xFFFFFFFF. The emulator doesn't support wraparound properly so it gives an error message of its own and a general protection fault.

Interesting - thanks for the correction. I assumed Bochs was moaning about invalid segment limits from an incorrectly selected..um..selector.

Cheers,
Adam

[White-spirit]

Thank you all for your help, maybe I must use Qemu instead of Bochs, but without debugger ... :s

Well, topic solved

[JamesM]

Thank you all for your help, maybe I must use Qemu instead of Bochs, but without debugger ... :s

Well, topic solved

You can use bochs, of course. Just don't try to fetch an unaligned multibyte value right from the top of the address space so it overflows!

[White-spirit]

Okay thanks