Docker/CI setup revealed problems with compiling on specific toolchain

[techdude17]

Hi all!

I've been working on moving my OS to a new repository and setting up CI. I was doing some local Docker testing when I discovered that the toolchain I built in my container would not produce a viable ELF file (it was not Multiboot compatible)

I opened a hex editor and took a look for the multiboot signature and found it positioned at 0x100000 in terms of file offset, so the file was now 1MB larger and totally invalid.

readelf gave the following output:

Code: Select all

Elf file type is EXEC (Executable file)
Entry point 0x100098
There is 1 program header, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000156218 0x00000000001c2971  RWE    0x1000
 

The file is being loaded at 0x0 and I'm not sure why. This again only happens on SOME LD versions (working on binutils 2.43, but not 2.38)

Here's my linker script:

Code: Select all

OUTPUT_FORMAT(elf64-x86-64)
ENTRY(_start)

SECTIONS
{
    /* Kernel is loaded at 1M */
    . = 1M;

    __kernel_start = .;

    /* Code section */
    .text BLOCK(4K) : ALIGN (4k)
    {
        __multiboot_start = .;
        KEEP(*(.multiboot))
        __multiboot_end = .;

        __bootstrap_start = .;
        *(.bootstrap)
        __bootstrap_end = .;

        __text_start = .;
        *(.text)
        __text_end = .;

        __ap_start = .;
        *(.ap_bootstrap)
        __ap_end = .;
    }

    /* Read-only data */
	.rodata BLOCK(4K) : ALIGN(4K)
	{
        __rodata_start = .;
		*(.rodata)
        __rodata_end = .;
	}

	/* Initialized data */
	.data BLOCK(4K) : ALIGN(4K)
	{
        __data_start = .;
		*(.data)
        __data_end = .;
	}

	/* BSS */
	.bss BLOCK(4K) : ALIGN(4K)
	{
        __bss_start = .;
		*(COMMON)
		*(.bss)
        __bss_end = .;
	}

    __kernel_end = .;
}

Anyone have a clue why this could be happening?

[Octocontrabass]

Your object files contain sections that aren't listed in your linker script, and the linker has decided that the 1MB of unused address space at the beginning of your binary is a great place to put them.

I couldn't tell you how to fix it without more information about the misplaced sections.

[techdude17]

Your object files contain sections that aren't listed in your linker script, and the linker has decided that the 1MB of unused address space at the beginning of your binary is a great place to put them.

I couldn't tell you how to fix it without more information about the misplaced sections.

They are compiled with -g for debug and that's all I can think of off the top of my head. If you've got a command I can try to run to see if you're right, then I'll gladly try.

[Octocontrabass]

I'd start with readelf to check your kernel's section headers ("readelf -S"). That will probably be enough to figure out what's wrong.

It might also help to share how you're building your binary.

[techdude17]

Did check that, first section was .text correctly positioned at VMA 0x100000 (incorrect file offset). Rest of them also looked very normal and followed .text.

I'm away right now but will check when I get home exact binary building commands. If I remember correctly, I compile GCC 11.4.0 and Binutils 2.38 with recommended commands.

I did get some errors installing libstdc v3 so I skipped it but compiled. That might've been what caused the problem now that I think about it - will recompile and test

[Octocontrabass]

Did check that, first section was .text correctly positioned at VMA 0x100000 (incorrect file offset).

Try setting max-page-size to 0x1000. The linker might be trying to optimize your binary for 2MB or 4MB pages.

[techdude17]

I did that when making my object files, but not when linking. I'll try it and see - thank you!

[techdude17]

Yep, that fixed it! Thank you for yet more good advice Octocontrabass