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.
Code:
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.