OSDev.org

Posted: **Tue Jul 13, 2010 1:34 am**

Hello, recently (after a few code rewrites), I decided to try to write my own bootloader. I found one tutorial for it, that set up the GDT and everything. Since my implementation didn't work at all for it, I decided to just copy the code directly, and it worked...sorta... whenever I try to call an external function from the main kernel C file, it triple-faults (and reboots) and doesn't even get to the kernel main function that calls the external function (verified by gdb). When I write out the code that the function I am trying to call is executing in the main function, it works fine. Tried it in Bochs and QEMU, both with the same result.

Since it would take up a bunch of room if I embedded it, I have attached: The source, and build script.

zOS-SRC.tar.gz: (36.73 KiB) Downloaded 46 times

If needed, qemu is being launched as such: (qemu -s -S -d int,cpu,pcall,cpu_reset -m 32 -fda boot.img -boot a)

Any help would be appreciated. Thanks.

Posted: **Tue Jul 13, 2010 8:19 am**

I think you made at least two mistakes:

You are jumping straight to 0x1000 after switching to protected mode in boot.asm. At this time there is just nothing at 0x1000. The BIOS only loads the first 512 Bytes from the floppy into RAM and jumps there. All other code you want to execute must be loaded by these first 512 Bytes. You are not doing that.
You are only linking the text-section to 0x1000. What about bss, data and rodata? Try using a linker script from the wiki.

I don't know what mkboot does exactly, since you didn't provide any sourcecode for this executable, so these two things can be wrong, but they can help you as a starting point.

Happy hacking

Posted: **Tue Jul 13, 2010 9:28 am**

Thanks. I knew there was something wrong with it. I have attached the makeboot source code.
Also, about jumping to 0x1000:
The code in the bootloader:

Code: Select all

        mov ah, 02h            ; READ SECTOR-command
        mov al, Ah              	; Number of sectors to read = 10
        mov ch, 0                ; Cylinder = 0
        mov cl, 02h             ; Sector = 2
        mov dh, 0               ; Head = 0
        int 13h                    ; Call interrupt 13h
        or ah, ah

Which is being run in the first 512 bytes is supposed to read 10 sectors starting at the second, which should be enough for the code until it gets to be 5kb.

Posted: **Tue Jul 13, 2010 9:44 am**

Yargh wrote: Which is being run in the first 512 bytes is supposed to read 10 sectors starting at the second, which should be enough for the code until it gets to be 5kb.

Huh! Sorry, I didn't see that. I just had a quick look over the code.

Another hint how to find the bug:
Try to disassemble the generated ELF with an objdump -d and verify by single stepping several locations of symbols, calculated addresses etc.
It is an annoying work, but sometimes necessary.

I had to do this last week when GCC messed up initialization of static objects in my c++ kernel which I cannot reproduce outside of my kernel. Code which was clearly generated by GCC just calculated a wrong address and jumped into delirium. I don't know why, but after moving some code around in the files, it finally worked.
Without singlestepping and kind of reversing the code I would have never found the cause of this error.

Posted: **Tue Jul 13, 2010 1:30 pm**

Using the C Kernel Barebones' linker script shown on the wiki, it does the exact same thing as when it is not.
I guess I have to figure out now why it won't let me compile bochs with debug support... whenever I compile it with debug support (running on mac), it doesn't change anything. Since I cannot enable debug mode in bochs for some odd reason, and I cannot use gdb/qemu because the kernel code isn't getting called, any ideas?

Posted: **Tue Jul 13, 2010 2:56 pm**

I'm only using bochs for assembly level debugging with the GUI debugger.

Try to use this configure commandline to get the debugger itself and the GTK GUI for it:

Code: Select all

./configure \
		--with-x11 \
		--enable-debugger \
		--enable-disasm \
		--enable-debugger-gui \
		--enable-smp \
		--enable-x86-64 \
		--enable-smp \
		--prefix=<choose an appropriate install path>

This is the command I'm using for my own toolchain build which works fine for me under Mac OS.

Here is the bochrc I'm using:

Code: Select all

andy@geekbook ~/Documents/devstuff/oskrempel/GeexOS [GIT: /master !]% cat resources/bochsrc.txt 
megs: 128
romimage: file=toolchain/i686-elf/share/bochs/BIOS-bochs-latest, address=0x00000
vgaromimage: file=toolchain/i686-elf/share/bochs/VGABIOS-lgpl-latest
floppya: 1_44=floppy.img, status=inserted
boot: a
log: bochsout.txt
mouse: enabled=0
clock: sync=realtime
cpu: ips=500000
com1: enabled=1, mode=file, dev=serialOut
display_library: x, options="gui_debug"

Note the last line, which enables the GUI debugger. As soon as you start bochs, the debugger should pop up and lets you disassemble memory locations, set breakpoints etc.

Of course you need to have X11 installed on your Mac OS, but the server is available on your Mac OS install DVDs.

Good luck!

OSDev.org

OS Doesn't even load when trying to run included function

OS Doesn't even load when trying to run included function

Re: OS Doesn't even load when trying to run included functio

Re: OS Doesn't even load when trying to run included functio

Re: OS Doesn't even load when trying to run included functio

Re: OS Doesn't even load when trying to run included functio

Re: OS Doesn't even load when trying to run included functio