Rust ELF executable appears to not be 'executable' type

[ThatCodingGuy89]

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

[Octocontrabass]

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

[ThatCodingGuy89]

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.

Code: Select all

readelf -h kernel.elf
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x7bc0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          4044680 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         12
  Size of section headers:           64 (bytes)
  Number of section headers:         43
  Section header string table index: 42

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.

[Octocontrabass]

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?

[ThatCodingGuy89]

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)