ld fails to find the entry symbol main when linking

Question

I am writing a simple hello world bootloader in C with inline assembly using this article. Nothing fancy, no kernel loading and other advanced topics. Just a plain old "hello world" message.

Here are my files:

boot.c

/* generate 16-bit code */
__asm__(".code16\n");
/* jump boot code entry */
__asm__("jmpl $0x0000, $main\n");

/* user defined function to print series of characters terminated by null 
character */
void printString(const char* pStr) {
    while (*pStr) {
      __asm__ __volatile__ (
           "int $0x10" : : "a"(0x0e00 | *pStr), "b"(0x0007)
      );
      ++pStr;
    }
}

void main() {
    /* calling the printString function passing string as an argument */
    printString("Hello, world!");
}

boot.ld

ENTRY(main);
SECTIONS
{
    . = 0x7C00;
    .text : AT(0x7C00)
    {
        *(.text);
    }
    .sig : AT(0x7DFE)
    {
        SHORT(0xaa55);
    }
}

I then ran the following commands: (different from the first article; adapted from another StackOverflow article as the commands in the first article won't work for me)

gcc -std=c99 -c -g -Os -march=i686 -m32 -ffreestanding -Wall -Werror boot.c -o boot.o

ld -static -T boot.ld -m elf_i386 -nostdlib --nmagic -o boot.elf boot.o

The first line compiles successfully, but I get errors upon executing the second line:

ld: warning: cannot find entry symbol main; defaulting to 0000000000007c00

boot.o:boot.c:(.text+0x2): undefined reference to 'main'

boot.o: In function 'main':

C:(...)/boot.c:16: undefined reference to '__main'

C:(...)/boot.c:16:(.text.startup+0xe): relocation truncated to fit: DISP16 against undefined symbol '__main'

What's wrong? I use Windows 10 x64 with the gcc compiler that comes with Dev-C++.

Answer 1

I'd suggest an i686-elf cross compiler rather than using a native windows compiler and tool chain. I think part of your problem is peculiarities related to the Windows i386pe format.

The .sig section is likely not being written at all since that unknown section probably isn't marked allocatable data. The result of that is the signature isn't written to the final binary file. It is also possible the virtual memory address (VMA) is not being set in boot.ld so it may not advance the boot signature into the last 2 bytes of the 512 byte sector. As well with the Windows format read only data will be placed in sections starting with .rdata. You'll want to make sure those are included after the data section and before the boot signature. Failure to do this will default the linker script into placing unprocessed input sections at the end beyond the boot signature.

Assuming you have made the changes as you mentioned in the comments about the extra underscores your files may work this way:

boot.ld:

ENTRY(__main);

SECTIONS
{
    . = 0x7C00;
    .text : AT(0x7C00)
    {
        *(.text);
    }
    .data :
    {
        *(.data);
        *(.rdata*);
    }
    .sig 0x7DFE : AT(0x7DFE) SUBALIGN(0)
    {
        SHORT(0xaa55);
    }
}

The commands to compile/link and adjust the .sig section to be a regular readonly allocated data section would look like:

gcc.exe -std=c99 -c -g -Os -march=i686 -m32 -ffreestanding -Wall -Werror boot.c -o boot.o
ld.exe -mi386pe -static -T boot.ld -nostdlib --nmagic -o boot.elf boot.o

# This adjusts the .sig section attributes and updates boot.elf 
objcopy --set-section-flags .sig=alloc,contents,load,data,readonly boot.elf boot.elf
# Convert to binary
objcopy -O binary boot.elf boot.bin

---

Other Observations

Your use of __asm__(".code16\n"); will not generate usable code for a bootloader. You'll want to use the experimental pseudo 16-bit code generation that forces the assembler to modify instructions to be compatible with 32-bit code but encoded to be usable in 16-bit real mode. You can do this by using __asm__(".code16gcc\n"); at the top of each C/C++ files.

---

This tutorial has some bad advice. The global level basic assembly statement that does the JMP to main may be relocated to somewhere other than the beginning of the bootloader (some optimization levels may cause this). The startup code doesn't set ES, DS, CS to 0x0000, nor does it set the SS:SP stack segment and pointer. This can cause problems.

---

If trying to run from a USB drive on real hardware you may find you'll need a Boot Parameter Block. This Stackoverflow Answer I wrote discusses this issue and a possible work around under Real Hardware / USB / Laptop Issues

---

Note: The only useful code that GCC currently generates is 32-bit code that can run in 16-bit real mode. This means that you can't expect this code to run on a processor earlier than a 386 like the 80186/80286/8086 etc.

My general recommendation is to not create bootloaders with GCC unless you know what you are really doing and understand all the nuances involved. Writing it in assembly is probably a much better idea.

If you want a C/C++ compiler that generates true 16-bit code you may wish to look at OpenWatcom