Stack Faults

[srg]

Hi

My code now works fine when loaded in DOS, but I now need the program to also work as a bin from a bootsector.

After converting it to a bin, it loads from the bootsector great in segment 1000h.

The problem is that when my code jumps to it's pmode code segment, it causes a stack fault. This is what Bochs streams at me:

00000723981i[CPU ] write_virtual_checks(): write beyond limit, r/w

[Pype.Clicker]

you should use a "jump far" command (possibly using modifying code) to enter pmode rather than your "push 8, push ax, retf" trick.
Playing with a not-yet-redefined stack between realmode and pmode seems dangerous, afaik


however, i'm pretty astonished you have "load_kernel_fat12" called from pmode ! i think loading while you're still in realmode will help you writing it ...

[srg]

Well I do now have

?????? Jmp 0x0008:ToHere

[Bits 32]

ToHere:

But I still get the exact same problem

As for the kernel load thing, I want to load my kernel from at the 1MB mark, the thing is that I don't want to use any of the silly "Unreal Mode" tricks for loading it into real mode. This way may be less tricky than that.

Also, once I have it in pmode, I wanted to stay there so I don't have to go through the hazards of possibly getting these problems again.

[Pype.Clicker]

yep, but keep in mind that no BIOS call will be avl. in pmode ... I doubt you're willing to add floppy driver and IDE/ATA support in your 2nd stage loader ...

[srg]

yep, but keep in mind that no BIOS call will be avl. in pmode ... I doubt you're willing to add floppy driver and IDE/ATA support in your 2nd stage loader ...

Yep that is the plan, I will add my own Floppy and IDE Access into my 2nd stage loader.

My problem at the moment is these stack faults.

BTW If I load this program with a DOS disk made by the DOS format /s command or the Windows "Make bootable MS-DOS disk", it loads fine.

BUT If I load it with a disk that I have done an SYS A: to (which when it starts up it shows the Windows 98 logo) I get these stack faults, which are the exact same problem as I'm having with loading it off a boot sector.

[srg]

I have commented out the code that comes after the jump the to pmode cs and have found the root cause, but I'm not sure what is wrong!

Here is what bochs says:

00000719761i[CPU ] write_virtual_checks(): write beyond limit, r/w
00000719761i[CPU ] -----------------------------------
00000719761i[CPU ] selector->index*8 + 7 = 807
00000719761i[CPU ] gdtr.limit = 39
00000719761i[CPU ] fetch_raw_descriptor: GDT: index > limit
00000719761i[CPU ] | EAX=60000011 EBX=00000010 ECX=00000000 EDX=00010000
00000719761i[CPU ] | ESP=00007be0 EBP=00007bfa ESI=00000fff EDI=00000086
00000719761i[CPU ] | IOPL=0 NV UP DI PL NZ NA PE NC
00000719761i[CPU ] | SEG selector base limit G D
00000719761i[CPU ] | SEG sltr(index|ti|rpl) base limit G D
00000719761i[CPU ] | DS:1000( 0000| 0| 0) 00010000 0000ffff 0 0
00000719761i[CPU ] | ES:1000( 0000| 0| 0) 00010000 0000ffff 0 0
00000719761i[CPU ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000719761i[CPU ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000719761i[CPU ] | SS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000719761i[CPU ] | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00000719761i[CPU ] | EIP=00010370 (0001036f)
00000719761i[CPU ] | CR0=0x60000011 CR1=0x00000000 CR2=0x00000000
00000719761i[CPU ] | CR3=0x00000000 CR4=0x00000000
00000719761i[CPU ] >> cf
00000719761i[CPU ] >> : iret
00000719761i[CPU ] -----------------------------------
00000719761p[CPU ] >>PANIC<< fetch_raw_descriptor: LDTR.valid=0
00000719761i[SYS ] Last time is 1043349864
# In bx_win32_gui_c::exit(void)!
========================================================================
Bochs is exiting with the following message:
[CPU ] fetch_raw_descriptor: LDTR.valid=0
========================================================================
00000719761i[CPU ] protected mode
00000719761i[CPU ] CS.d_b = 32 bit
00000719761i[CPU ] SS.d_b = 16 bit
00000719761i[CPU ] | EAX=60000011 EBX=00000010 ECX=00000000 EDX=00010000
00000719761i[CPU ] | ESP=00007bd0 EBP=00007bfa ESI=00000fff EDI=00000086
00000719761i[CPU ] | IOPL=0 NV UP DI PL NZ NA PE NC
00000719761i[CPU ] | SEG selector base limit G D
00000719761i[CPU ] | SEG sltr(index|ti|rpl) base limit G D
00000719761i[CPU ] | DS:1000( 0000| 0| 0) 00010000 0000ffff 0 0
00000719761i[CPU ] | ES:1000( 0000| 0| 0) 00010000 0000ffff 0 0
00000719761i[CPU ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000719761i[CPU ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000719761i[CPU ] | SS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000719761i[CPU ] | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00000719761i[CPU ] | EIP=00010370 (0001036f)
00000719761i[CPU ] | CR0=0x60000011 CR1=0x00000000 CR2=0x00000000
00000719761i[CPU ] | CR3=0x00000000 CR4=0x00000000
00000719761i[CPU ] >> cf
00000719761i[CPU ] >> : iret
00000719761i[CTRL ] quit_sim called with exit code 1

[srg]

hmmm Inturiging, there is some instructions here that I did not write that are being executed!!

It's one of these that are causing the fault

here they are:

push EBX

inc DS:[EAX]
this one causes the fault

[Pype.Clicker]

did you check eip was somewhere it could reach ?

and why the heck do some of your EXC handlers do "pop eax ; xor eax,eax" ?

Are you trying to remove the error code ?
if so, why don't you just "add esp, 4" ?

btw, where did you find the instructions being executed ? it appears to me from the BOCHS output you give that the faulty code comes from a IRET ...

you definitely should try some objdump -x and -d on your kernel object file ...

[srg]

objdump says file format not recognised!!!!!!!!

I was using the one with cygwin

I'll try the one with djgpp

[srg]

objdump doesn't work

[Pype.Clicker]

objdump doesn't work

what's your kernel's object format ? COFF? PE ? ELF?
It must not be a plain binary or objdump will not work...

[srg]

It also doesn't work on the EXE file, which is a DOS EXE.

Or does it only work with .obj files (as the name would suggest :-[ )

BTW This is what I'm currently getting in Bochs:

00001073273i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073276i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073279i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073282i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073285i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073288i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073291i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073294i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073297i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073300i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073303i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073306i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073309i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073312i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073315i[CPU ] write_virtual_checks(): write beyond limit, r/w
00001073318i[CPU ] write_virtual_checks(): write beyond limit, r/w

Over and over and over

I also sometimes get a Tripple Stack Fault

[srg]

This problem is getting VERY strange!

The cause of the problem are two instructions that are called over and over and over again:

push EBX

inc DS:[EAX]

these cause the "write beyond limit" errors

The wiered thing is that according to EIP, the instructions that should be being executed are my data register settin code, but all that is actually happening are these two instructions constanly looping!!

The write beyond limit error is caused by the inc instruction incrementing a 32-bit value in an old 16-bit real mode segment.

The eventual stack fault is being caused by the fact that one of these looping instructions is a push, this is filling up the stack.

Why is the CPU executing these rouge instructions and ignoring my program!!!!!!!!! >:(

Even if I add a hlt instruction after my JMP, these rouge instructions get called.

Thanks

[Pype.Clicker]

from what i can see from your BOCHS info, the base of your data selector is not 0, but 0x10000, and not your CS segment. I don't know if this is made by purpose, but i think you're not expecting [ds:0] to be different from [cs:0], are you ?

moreover, it means that if your code wasn't ORGanized so that cs=0, jmping to the cs_selector will suddenly break all your cs addresses...

[srg]

In what is (for me anyway) a eurika moment, I have come to the same conclustion, I am fixing the code now!