-2

I've been attempting to compile all my code using a Makefile and Dockerfile, but everytime I use make build-x86_64, I keep getting an error saying:

x86_64-elf-ld: warning: cannot find entry symbol start; defaulting to 0000000000100150

If I'm not wrong, this error is probably coming from my main64.asm file. The code for that file being this:

global long_mode_start
extern kernel_main

section .text
bits 64
long_mode_start:
    ; load null into all data segment registers
    mov ax, 0
    mov ss, ax
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax

    call kernel_main
    hlt

(If you were wondering, I was following a tutorial and they didn't mention this error occuring.)

All I know is that this is a error related to assembly code, but I don't know which file the error comes from plus I don't know how to fix the error, does anybody know how to fix it? Thanks :)

Michael Petch
  • 43,801
  • 8
  • 98
  • 174
ARMathieu
  • 7
  • 3
  • It comes from linking the output file. It doesn't come from any input file, it comes from *lack of* an input file defining `_start` as a global symbol. If you aren't writing one yourself, that would normally be one of the CRT files (like `/usr/lib/crt1.o` on GNU/Linux) that GCC or clang will link unless you tell them not to (with `-nostartfiles`). Without an actual [mcve] of a command run by your Makefile, we can't tell you what's wrong with it, or what the appropriate fix would be. From x86-64-elf, I assume you're linking for GNU/Linux, rather than MacOS or *BSD, or Windows... – Peter Cordes May 28 '22 at 07:19
  • In a tiny hand-written asm program, this warning is normal if you left out some lines on purpose because you know the default is fine (execution starting at the top of `.text`.) – Peter Cordes May 28 '22 at 07:19
  • It is impossible to diagnose your problem without seeing your code and the commands to build it. Please [edit] your question and add these details. I will then take back my downvote. – fuz May 28 '22 at 08:36
  • 1
    Are you using multiboot wiht something like GRUB? I see this appears to be OSDev related and the address in question is just above the 1MiB mark. If this is multiboot then you should be able to rename your entry point to `start` or use the `-e nameofentrypoint` when linking where `nameofentrypoint` is the address to start running code from if it's not `start`. If using a linker script you can tell it what label to use as an entry point using `ENTRY()`. – Michael Petch May 29 '22 at 04:20
  • Interesting, Intel's pseudo-code documentation for `mov Sreg, r/m` says loading a NULL (0) selector into `ss` *always* faults with GP(0) (https://www.felixcloutier.com/x86/mov#operation). But the [64-bit-mode exceptions section of the same entry](https://www.felixcloutier.com/x86/mov#64-bit-mode-exceptions) says that only happens for CPL=3 (user-space) or CPL!=RPL. So the manual seems to conflict with itself. Or maybe `#GP(selector)` with selector=0 triggers for one of the reasons mentioned. Or maybe it doesn't if this tutorial actually works! You still need a GDT for CS, though. – Peter Cordes May 29 '22 at 04:24
  • @MichaelPetch Yeah, I'm using grub and multiboot, as that's what the tutorial wanted me to use when coding. – ARMathieu May 29 '22 at 04:52
  • @PeterCordes : The pseudo code in question is for protected mode (see the preamble), not long mode. I have discussed that here https://stackoverflow.com/questions/57436125/should-using-mov-instruction-to-set-ss-to-0x0000-cause-fault-gp0-in-64-bit-mo – Michael Petch May 29 '22 at 04:54
  • 1
    Does the tutorial use a linker script for linking? If so is there an `ENTRY()` in it? You should set the entry point to where GRUB should start executing which would likely be the label where the 32-bit code starts. – Michael Petch May 29 '22 at 04:56
  • 1
    Seems I found a Rust demo that this might have come from. if so there is a `linker.ld` file with an `ENTRY(start)` at the top and the assembly code has a `start` label in it.Any chance you changed the name of the entry point (where 32-bit code execution should start)? If so just update `linker.ld` to that label and make sure the label is made global in the assembly file so the linker can find it as an entry point. – Michael Petch May 29 '22 at 05:27
  • @MichaelPetch I'm sure that've I made the start label global. I've checked and I'm sure that's not the cause of this error. – ARMathieu May 31 '22 at 04:18
  • For some reason it can't find it since the error is `warning: cannot find entry symbol start`. When the ENTRY label can't be found it will use the address of the first `.text` section of the first object file passed to the linker. Do you have a project on github (or other online repository) that we can look at? – Michael Petch May 31 '22 at 04:24
  • @MichaelPetch here's a link to a private resp for testing: https://github.com/ARMathieu/cloudOS-testresp – ARMathieu May 31 '22 at 04:38
  • @MichaelPetch think i might off messed around with the settings too much you can check it out here https://github.com/ARMathieu/cloudOStest – ARMathieu May 31 '22 at 05:03
  • @MichaelPetch srry i forgot to upload the files, im just tired and i eventually have school to go to so i rushed everything, so now i just uploaded the files on the main commit – ARMathieu May 31 '22 at 05:29
  • 1
    In `main.asm` your label isn't `start` but is `_start` . On line 6 change `_start:` to `start:` – Michael Petch May 31 '22 at 05:37

0 Answers0