General Issues

[Uranium]

I was into OS Development a couple of months ago then with college etc... I drifted away from it.

Anyway more to the point, using Bran's Kernel Development tutorial I attempted to build the base of a simple operating system for examining the media on drives.

It all compiles fine without warning but when I load up QEMU bugger all happens, apart from QEMU freezing and then "Not Responding". When I tried loading it up on an old computer (I'm talking was running Windows 95), it just rebooted after GRUB had loaded it.

I've attached the source tree etc... to the post, if someone could have a quick look through it and see if they can spot something that would be great.

Cheers guys.

http://www.filefactory.com/file/80bafc/n/MediaOS_zip

[Combuster]

Have you at least tried Bochs? It will usually give you a more descriptive error than "lockup" or "reboot", together with the location of the error

[Uranium]

Solved it, one of the issues was that I wasn't using -std-vga as a QEMU parameter and the other was that I accidently defined word as "unsigned int" instead of "unsigned short".

Kill me now =p

[Walling]

Okay, you solved the problem. But do you know you can connect GDB to QEMU to debug your kernel? It is really nice. If you compile your kernel with debugging symbols GDB can single-step in your ASM/C/C++ code with the source code lines shown. You can set breakpoints on functions and you can access/change variables. I have a linker script with debugging symbols if you're interested.

[Troy Martin]

@Uranium: *BLAM* *BLAM* *BLAM*

@Walling: Don't those symbols make the kernel bigger, or are they in a different file? (I'm all asm here, makes coding easier.)

[Walling]

@Walling: Don't those symbols make the kernel bigger, or are they in a different file? (I'm all asm here, makes coding easier.)

Yes. What I do is to make two versions of the kernel. I make the one with debugging symbols, and then I strip away the symbols (but the internal addresses remain the same). The stripped version is the one GRUB gets to load. The other one I pass to GDB, like this:

Code: Select all

# ... make boot.iso with kernel-debug-stripped.elf ...
# qemu -boot d -cdrom boot.iso -s -S &
# gdb --quiet --se=kernel-debug-with-symbols.elf
(gdb) target remote :1234
Remote debugging using :1234
0x0000fff0 in ?? ()
(gdb) b multiboot_entry
Breakpoint 1 at 0x100030: file src/multiboot_entry.asm, line 66.
(gdb) c
Continuing.

Breakpoint 1, multiboot_entry () at src/multiboot_entry.asm:66
66	    mov   esp, stack_top
Current language:  auto; currently asm
(gdb) 

[Solar]

Some googling came up with this command sequence to get a seperate symbol file for your executable:

Code: Select all

objcopy --only-keep-debug <in-executable> <out-symbol-file>
objcopy --add-gnu-debuglink=<out-symbol-file> <in-executable>
strip --strip-debug <in-executable>

[Walling]

Some googling came up with this command sequence to get a seperate symbol file for your executable

Nice. I tried it and it works, but the second objcopy doesn't seem to add anything. I also use this objcopy to strip away all information and only keep .text, .data and .bss sections:

Code: Select all

objcopy -j.text -j.data -j.bss -S <in-file> <out-file completely stripped>

I don't need to relocate the kernel, so I discard all symbols with -S. It becomes smaller (25%). And can I be sure that any Multiboot compliant boot loader obey the LOAD flag of ELF sections and doesn't load the debugging sections? The debugging sections have a load address of 0x0. It would overwrite the IVT table.