[Solved] Linking c file without including it causes reboo...

[BluCode]

I am trying to develop an OS, mainly to learn about whats going on 'under the hood', and I am having trouble enabling paging. When I simply link the paging.c file with the rest of my c files, without ever mentioning it in another file, I get an endless reboot cycle. If I don't link the file but keep everything else the same, it works. So far I have tried to move my stack out of the way (from 0x9000 to 0xF000), and it has had no effect. I am open to suggestions and I am willing to post my code if needed.

My linking command (in my Makefile):

Code: Select all

ld -Ttext 0x1000 -m elf_i386 -o kernel/kernel.bin $^ --oformat binary

Hope you see something I don't.

[alexfru]

What about the order in which your C files end up in the binary? May that be screwing up the entry point?

[goku420]

Two things:

- Why run ld manually? Linking with gcc or g++ will call the linker under the hood

- Why specify text manually? You might as well use a linker script.

Also 0x1000 is unusual. The most common place to load the kernel is at the 1MB mark as that's safe enough to avoid anything that's loaded below it.

[iansjack]

Run it under a debugger.

[mallard]

A guess; since you're loading your kernel at a "low" address, you have (approximately; there are complications) 636KB (since you're loading at the 4KB mark) of memory before you hit the legacy ROM/MMIO area (the 384KB just below the 1MB boundary).

When you link this extra file into your kernel, it increases the size of the file so it no longer fits into that small RAM space, so your loader attempts to overwrite ROM, write to non-existent memory, etc. and the system resets in response.

[BluCode]

Wow, thanks for all the replies!

What about the order in which your C files end up in the binary? May that be screwing up the entry point?

No, I use an entry assembly script that calls my 'start' c function, so thats not it.

- Why run ld manually? Linking with gcc or g++ will call the linker under the hood

- Why specify text manually? You might as well use a linker script.

Also 0x1000 is unusual. The most common place to load the kernel is at the 1MB mark as that's safe enough to avoid anything that's loaded below it.

1) I've heard about that, but never found how to use it. Please elaborate on how I could do that.

2) I have tried using a linker script but it messed up my .rodata sections (I couldn't print pre-defined strings). Any help with that would also be appreciated.

3) I am using my own bootloader, which, being 16 bit and only having a 16 bit disk read function, can only load the kernel to 0xFFFF.

Run it under a debugger.

Please elaborate, it sounds useful in the future.

A guess; since you're loading your kernel at a "low" address, you have (approximately; there are complications) 636KB (since you're loading at the 4KB mark) of memory before you hit the legacy ROM/MMIO area (the 384KB just below the 1MB boundary).

When you link this extra file into your kernel, it increases the size of the file so it no longer fits into that small RAM space, so your loader attempts to overwrite ROM, write to non-existent memory, etc. and the system resets in response.

Good insight, but I can't figure out how I would go about loading the kernel somewhere high, like 1M, seeing as I am using a 16 bit bootloader and 16 bit disk read function.

Thanks for all your help so far!

[iansjack]

Presumably you are testing your kernel with an emulator/virtual machine rather than on real hardware. (If not, you should.) Qemu is a good choice, and it can be used in conjunction with gdb to debug the kernel: http://wiki.qemu.org/Documentation/Debugging

[BluCode]

Yes, I am using qemu. I tried to use gdb but I couldn't figure out how to get a symbol file from my kernel.bin. It would be really advantageous to get that working though.

[Octocontrabass]

Good insight, but I can't figure out how I would go about loading the kernel somewhere high, like 1M, seeing as I am using a 16 bit bootloader and 16 bit disk read function.

If your kernel is small enough to fit in low memory, you can load it all in real mode and then copy it above 1M after you switch to protected mode.

It's also possible to load part of the kernel in real mode, switch to protected mode to copy that part above 1M, then switch back to real mode and repeat until the entire kernel is loaded.

My favorite option is to install a GPF handler that switches to unreal mode for transparent 32-bit addressing, although you probably don't need something that complicated.

[iansjack]

Yes, I am using qemu. I tried to use gdb but I couldn't figure out how to get a symbol file from my kernel.bin. It would be really advantageous to get that working though.

Produce an elf file as well as a binary file, and use that as the file you "load" to provide symbols. Or, without symbols, you can still use gdb to debug at the assembler level.

[MichaelPetch]

Yes, I am using qemu. I tried to use gdb but I couldn't figure out how to get a symbol file from my kernel.bin. It would be really advantageous to get that working though.

An observation. If you want a symbol file don't use GCC/LD to output as binary. Output as ELF (with the symbols) and then use Objcopy to convert the ELF to binary.

Code: Select all

ld -Ttext 0x1000 -m elf_i386 -o kernel/kernel.elf <list of objects>
objcopy -O binary kernel.elf kernel.bin

this would generate an intermediate ELF file called `kernel.elf` that is then converted into `kernel.bin`.

[MichaelPetch]

If you had a project available (github etc) we could have a look.

[eryjus]

ld -Ttext 0x1000 -m elf_i386 -o kernel/kernel.elf <list of objects>
objcopy -O binary kernel.elf kernel.bin

Don't forget you need a cross compiler: http://wiki.osdev.org/GCC_Cross-Compiler

[LtG]

Didn't see it mentioned yet, but you should think if you want to do osdev or write a bootloader, the two are almost completely different, in design and goals.

If you don't care about bootloaders then use GRUB or some other existing one, and it's their responsibility to load your binary, if you want to do a bootloader then do that, but it doesn't really have much to do with osdev, except it's job is to load some OS.

[BluCode]

If your kernel is small enough to fit in low memory, you can load it all in real mode and then copy it above 1M after you switch to protected mode.

It's also possible to load part of the kernel in real mode, switch to protected mode to copy that part above 1M, then switch back to real mode and repeat until the entire kernel is loaded.

My favorite option is to install a GPF handler that switches to unreal mode for transparent 32-bit addressing, although you probably don't need something that complicated.

All good ideas, I'll look into them in the future.

Produce an elf file as well as a binary file, and use that as the file you "load" to provide symbols. Or, without symbols, you can still use gdb to debug at the assembler level.

An observation. If you want a symbol file don't use GCC/LD to output as binary. Output as ELF (with the symbols) and then use Objcopy to convert the ELF to binary.

Code: Select all

ld -Ttext 0x1000 -m elf_i386 -o kernel/kernel.elf <list of objects>
objcopy -O binary kernel.elf kernel.bin

this would generate an intermediate ELF file called `kernel.elf` that is then converted into `kernel.bin`.

Using these two replies and the wiki article on debugging with QEMU I got it working, thanks!

If you had a project available (github etc) we could have a look.

I'll probably move there soon, and I'll let you know if and when I do.

Didn't see it mentioned yet, but you should think if you want to do osdev or write a bootloader, the two are almost completely different, in design and goals.

If you don't care about bootloaders then use GRUB or some other existing one, and it's their responsibility to load your binary, if you want to do a bootloader then do that, but it doesn't really have much to do with osdev, except it's job is to load some OS.

Good point, but since this is mainly to learn about all of whats going on under the hood I'm doing both, please and thank you.

Also good and bad news, I solved the original issue, I wasn't reading enough sectors from the disk. The bad news is that paging isn't working, but thanks to you guys I should be able to use gdb and find the problem.