Skip to content

elf: not a valid i386 ELF executable; couldn't start /bin/clock.exe #298

Closed

Description

@Artyomka628

When running build-cross-compiler.sh there were a lot of errors in the files.
In the end, several makefiles did not run.
After building the kernel, not a single program was launched, just like before the build.
What system do you need to run this on in order to build it normally?

Activity

  1. dthain commented on Jun 30, 2025

    @dthain
    Owner

    Hello, I normally build the code on a x86_64 Linux machine running RHEL 7.9 with gcc 4.8.5. It builds and runs without the cross compiler. What's your setup?

  2. tkchia commented on Jan 4, 2026

    @tkchia

    Good day @dthain,

    I have encountered the same error message ("elf: not a valid i386 ELF executable"), after building everything via make, with GCC 13.3.0 and Binutils ld 2.4.2 on Ubuntu Linux.

    I checked the clock.exe output with the host readelf tool -- there was a load command (for the ELF headers) for virtual address 0x7ffff000. I am guessing this was why the Basekernel kernel rejected it (?).

    $ readelf -hl user/clock.exe
    ELF Header:
      Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
      Class:                             ELF32
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              EXEC (Executable file)
      Machine:                           Intel 80386
      Version:                           0x1
      Entry point address:               0x80000000
      Start of program headers:          52 (bytes into file)
      Start of section headers:          80684 (bytes into file)
      Flags:                             0x0
      Size of this header:               52 (bytes)
      Size of program headers:           32 (bytes)
      Number of program headers:         5
      Size of section headers:           40 (bytes)
      Number of section headers:         16
      Section header string table index: 15
    
    Program Headers:
      Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
      LOAD           0x000000 0x7ffff000 0x7ffff000 0x000d4 0x000d4 R   0x1000
      LOAD           0x001000 0x80000000 0x80000000 0x06be2 0x06be2 R E 0x1000
      LOAD           0x008000 0x80007000 0x80007000 0x01044 0x01044 R   0x1000
      LOAD           0x000000 0x80009000 0x80009000 0x00000 0x01238 RW  0x1000
      GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
    
     Section to Segment mapping:
      Segment Sections...
       00     
       01     .text 
       02     .rodata .eh_frame 
       03     .bss 
       04     
    

    I have also enclosed the ELF file output for reference.

    Thank you!

  3. dthain commented on Jan 5, 2026

    @dthain
    Owner

    Thanks, that is helpful info.

    You are quite correct, basekernel does not like the section that wants to be loaded at 0x7ffff000, which is not in user address space.

    Let me take a look and see why the linker is choosing that address. It looks suspiciously like a Linux top-of-stack address...

  4. dthain commented on Jan 6, 2026

    @dthain
    Owner

    @tkchia thanks for the detailed bug report, can you try out PR #299 and let me know if it solves your problem?

  5. tkchia commented on Jan 8, 2026

    @tkchia

    Good day @dthain,

    I checked out and built revision 6426849, and I can run bin/clock.exe now. Thank you!

  6. dthain commented on Jan 8, 2026

    @dthain
    Owner

    Glad it worked for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions