Page 4 of 4
Posted: Fri May 09, 2008 11:26 am
by JamesM
Combuster wrote: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
Posted: Fri May 09, 2008 12:15 pm
by 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.
Posted: Sat May 10, 2008 4:11 am
by White-spirit
Combuster wrote: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
Posted: Mon May 12, 2008 1:27 am
by 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.
Posted: Mon May 12, 2008 6:12 am
by 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
Posted: Mon May 12, 2008 6:31 am
by 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
Posted: Mon May 12, 2008 6:53 am
by 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 .
Posted: Mon May 12, 2008 7:13 am
by 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
Posted: Mon May 12, 2008 7:16 am
by White-spirit
Thank you, and what about the GPFs after the page fault in Bochs ?
Posted: Mon May 12, 2008 7:48 am
by 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
Posted: Mon May 12, 2008 8:14 am
by JamesM
AJ wrote: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
Posted: Mon May 12, 2008 8:20 am
by AJ
JamesM wrote: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
Posted: Mon May 12, 2008 11:19 am
by White-spirit
Thank you all for your help, maybe I must use Qemu instead of Bochs, but without debugger ... :s
Well, topic solved
Posted: Mon May 12, 2008 11:25 am
by JamesM
White-spirit wrote: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!
Posted: Mon May 12, 2008 11:29 am
by White-spirit
Okay thanks
