OSDev.org

i started rearranging my kernel and now it reboots all the time whenever i include files with my kernel:
(and i dont even call any of the functino in the included files). bochs says its running in bogus memory...anyone know why this woud happen?
#include "file.cpp"

by making your kernel larger, you may experience various problem, including (but not limited to)
- your bootloader can't deal with that much bytes
- you were expecting asm("jmp start") to be compiled first because
it was the very first line of kernel.c (or whatever you called it ,
but now, #include stuff is the first
- a misinitialized pointer was pointing to garbage memory and now it
refers to some "useful" area which shouldn't be overwritten ...

These are the most common error sources people have met this far ... the best way of tracking your error might be to ask bochs to display any CALL instruction so that you can see from where you jumped to b0gus mem0ry

Don't use #include with .CPP files.

Don't use #include with any file that contains function or variable definitions (declarations are OK).

at the beginnign of my kernel.c i tried putting:
asm("hlt");

ant it seems wherever i set "entry" to using LD..the hlt instruction is always read so why does this happen? also im not sure if i have a new version of GCC or somethin but i no longer have to put "_" in front of the function names....anyone also seen this?

slacker wrote:ant it seems wherever i set "entry" to using LD..the hlt instruction is always read so why does this happen?

If you're using flat binary, the entry keyword is ignored. Execution starts wherever your bootloader jumps to.

also im not sure if i have a new version of GCC or somethin but i no longer have to put "_" in front of the function names....anyone also seen this?

This depends mainly on the output format. If you're using ELF, they're not needed; if you're using COFF or PE, they are.

what formats support the entry keyword?

Everything except binary.

both ELF, COFF and A.OUT support it. If needed, you can use the small COFF2SFS tool i wrote for clicker, which prepends a flat binary with a 16 bytes header containing:
- the size of the datas to be loaded (i.e. length of .text and .data)
- the size of memory required for loading (i.e. length of .text + .data + .bss). This also allow for BSS cleaning by the loader
- a 32-bits magic identifier which is set to 'KERN' by default
- the offset of the entry point (where the loader should jump to

COFF2SFS assumes the COFF file is flat and requires no relocation at all (this is the job of the linker script).

I also have ELF2SFS
which produces the very same kind of "executable", but from an ELF file.

both are located under tools/misc and may require some header files, etc.

but i was compiling and linking and a.out file to a kernel.bin file and the entry was working..there are several tutorials on osdev.neoapges.net that link outputting a binary file...

it works as long as you have a "jump start" assembly statement compiled as the very first bytes of kernel.bin ... by #including stuff, you can break that magic property and start executing datas, or whatever ...

sounds like you were linking it out of order and your first bit of code was not your crt0 stub stuff.

make sure you link your jump start code at the begining as the first object module.