Linker error in Post-02 with custom 32-bit bootloader about blog_os HOT 9 CLOSED

How are you linking the code? It looks like you are invoking the linker yourself rather than having rustc invoke it for you. You may be missing necessary linker flags.

from blog_os.

How are you linking the code? It looks like you are invoking the linker yourself rather than having rustc invoke it for you. You may be missing necessary linker flags.

After compiling it in rustc, I'm using the command i686-elf-ld -o tmp/kernel.bin -Ttext 0x1000 tmp/kernel_entry.o tmp/kernel.o --oformat binary with the compiled .o file being kernel.o, and kernel_entry being an assembly script to import and run _start.

from blog_os.

How did you get that kernel.o file? If you literally passed --emit obj, that will not work. That will not include the machine code for dependencies. What you could do however is compile with the staticlib crate type and then link the resulting libkernel.a. This bundles all dependencies.

from blog_os.

What would the config need to look like in order to do that?

from blog_os.

In Cargo.toml you can add

[lib]
crate-type = ["staticlib"]

from blog_os.

Recompiling it with that change, as well as changing the file name from main to lib, then copying the .a file from target/i686/debug, it produced a linking error since it was using a GOT with PIE enabled. When I disabled PIE, the script compiled correctly and linked properly, but running it in qemu gets stuck in a boot loop of flashing the "SeaBIOS" header as well as "Booting from hard disk", then going to a blank screen, then repeating.

from blog_os.

The bootloader crate only supports booting x86_64 kernels, not 32-bit kernels.

from blog_os.

The bootloader crate only supports booting x86_64 kernels, not 32-bit kernels.

I am not using the bootloader crate at all. As I mentioned before, I'm using my own bootloader

from blog_os.

Ah, I missed that! In that case, you probably have to debug your bootloader. You can either connect gdb and step through the assembly to see where it fails, or you use QEMU's -d int flag to see which exceptions occur where. If course you can also insert endless loops at various stages in your bootloader to narrow down which part causes the crash.

from blog_os.