0

I'm having issues in specifying the entry point for my hobby OS kernel.

There is a simple bootloader that loads the kernel code to 0x6400000 address and jumps there.

Then I have this linker command which outputs kernel with the starting address:

ld --Ttext 0x6400000 -m elf_i386 --oformat binary -e kmain main.o -o main.bin

There's main.cc with the entry point function:

void kmain() { // ... }

Everything works fine as long as kmain() is the very first defined function. If it's not:

void do_smth() { // ... }

void kmain() 
{
    do_smth();
}

Then ld (and lld) ignores the -e kmain argument, and makes the do_smth() an entry point.

How could I force ld to make kmain() an entry point with an address of 0x6400000?

PovilasB
  • 1,488
  • 1
  • 15
  • 25
  • Possible duplicate of [GCC: how to tell GCC to put the 'main' function at the start of the .text section?](https://stackoverflow.com/questions/19470666/gcc-how-to-tell-gcc-to-put-the-main-function-at-the-start-of-the-text-sectio) – Eugene Sh. Jul 05 '17 at 13:51
  • Possible duplicate of [Change entry point with gnu linker](https://stackoverflow.com/questions/42301831/change-entry-point-with-gnu-linker) – rustyx Jul 05 '17 at 13:52
  • 2
    The ELF entry point will be correctly set to the symbol kmain. But you specified _binary_ as output format! So you do not have an ELF header any more specifying kmain as entry. What you really want is probably to have kmain at the very beginning of your binary, correct? – Ctx Jul 05 '17 at 14:14
  • @Ctx yes, that's the case. – PovilasB Jul 06 '17 at 09:42
  • 1
    Is the entry point parameter completely unused when linking to binary format? – Pyjong Oct 02 '17 at 15:18
  • 1
    @Pyjong yes, from what I've observed, it's unused. – PovilasB Oct 03 '17 at 10:44
  • @PovilasB Ok, thanks! – Pyjong Oct 03 '17 at 12:52

0 Answers0