OSDev.org

What I mean by "Rust ELF executable appears to not be 'executable' type" is that the executable
produced by the Rust compiler (with settings following https://os.phil-opp.com/) has ELF header position 16-17
(one u16, not two numbers) set to zero. (I have checked this by both looking at the file in a hex editor and via seeing what my bootloader does with it)

This does not appear to be a valid value for that field, as per https://wiki.osdev.org/ELF#Header. The only valid value for my bootloader
to accept the kernel as valid is 2, which marks the ELF file as being 'executable type'. I have honestly no idea why this is the case.

Here's my repo, keep in mind I have modified the result of the first few posts (as in, the first few posts of the "Writing an OS in Rust" blog previously mentioned)
by grafting the resulting Rust executable onto an existing bootloader that did somewhat work with a C-based kernel. (For UEFI compatibility)
https://github.com/ThatCodingGuy86/MimosaOS

Does the rest of the ELF header look normal? You can use readelf or objdump to examine it.

Octocontrabass wrote:Does the rest of the ELF header look normal? You can use readelf or objdump to examine it.

I actually did do that, just forgot to include it. The thing that stuck out was that the "Type" was "DYN (Shared object file)"
which seems... weird, and could be the reason that the field I mentioned is set to zero.
Oh, and while poking through it with a hex editor, I also noticed references to .so libs, which is concerning when this should be statically linked...
Something seems to be deeply wrong with the way I have this set up.

I was correct about that, I had accidentally been getting the kernel ELF file from the wrong directory, so no matter what I did,
it didn't actually affect the file. I've fixed that now, and the file is much shorter and doesn't have the weird references to .so libs.
Still has the original problem though.

Nope, I did fix the problem. I managed to get the file from the wrong directory again, now it doesn't display the error, but nothing seems to happen when the kernel
should be executing. I'm going to put that in a separate topic though, as it likely isn't related to this error.

ThatCodingGuy89 wrote:I actually did do that, just forgot to include it. The thing that stuck out was that the "Type" was "DYN (Shared object file)"
which seems... weird, and could be the reason that the field I mentioned is set to zero.

It means the value at offset 16 is 3, not zero. Are you sure you're looking at offset 16 and not offset 0x16?

Octocontrabass wrote:

ThatCodingGuy89 wrote:I actually did do that, just forgot to include it. The thing that stuck out was that the "Type" was "DYN (Shared object file)"
which seems... weird, and could be the reason that the field I mentioned is set to zero.

It means the value at offset 16 is 3, not zero. Are you sure you're looking at offset 16 and not offset 0x16?

Very sure. In the bootloader and the hex editor, the address is entered in decimal.

Anyways, this doesn't matter anymore as I fixed the issue. Now I've encountered a new issue,
which is that the kernel doesn't display anything, even though it should. (which I made a new post for as it isn't likely to be related)