Bona Fide OS Tutorial ld warning (entry symbol not found)

[Fencer]

Hi,

I'm following the Bona Fide Tutorial (http://www.osdever.net/bkerndev/index.php) and it all works well till I try to link the object files.
The output is:
i586-elf-ld: warning: cannot find entry symbol start; defaulting to 00100000

When ignoring this message the kernel will still boot, but I'm not sure weather this warning will make trouble in the future.

This is an extract of the start.s file where the symbol start is defined (and I made sure that start.o is included in the link)

Code: Select all

global start;
[BITS 32]

start:
    mov esp, _sys_stack     ; This points the stack to our new stack area
    jmp stublet
.....(rest of file)

(I attached the linker script)

My Questions:
Why is this warning there?
Will it make trouble?
How can I get rid of it?

Greetings
Fencer

[kop99]

That warning isn't serious.

And, try following...

Code: Select all

  . = 0x00100000

  .text phys : AT(phys) {
    code = .;
    *(.text)
    *(.rodata)
    . = ALIGN(4096);
  }

. = 0x00100000 part is inserted...

[JamesM]

Hi,

The warning is serious.

Are you sure the error message is as you stated:

Code: Select all

i586-elf-ld: warning: cannot find entry symbol start; defaulting to 00100000

Are you certain that the message does not read

Code: Select all

i586-elf-ld: warning: cannot find entry symbol _start; defaulting to 00100000

? Note the preceding underscore.

Cheers,

James

[Fencer]

yes I'm sure
and I checked it before. My first thought was exactly this.

[Firestryke31]

As a quick, temporary test "fix" you might try this:

Code: Select all

global start;
global _start;
[BITS 32]

start:
_start:
    mov esp, _sys_stack     ; This points the stack to our new stack area
    jmp stublet
.....(rest of file)

Just in case it's looking for the underscore anyway.

[xDDunce]

i had this exact same error just yesterday to be exact. i started an OS using just NASM and it's really interesting.

anyway, i fixed this problem by putting "section .text" just after [bits 32] and then declaring globals and externs etc.

so it should look like:

Code: Select all

[Bits 32]
section .text

global start

;; my multiboot header went here, but that's just preference

start:
     mov esp, _sys_stack
     ;;etc...

Cheers,
James.

[Fencer]

Thats it. thank you all

[ehenkes]

section .text

Yes, this helps. I migrated from aout format to coff format. With aout there was no problem (ld version 2.13), but coff did not find the label and had problems with _function ("undefined reference"). "section.text" solved these problems fully. Can anybody explain the reason, why aout is more flexible than coff regarding this point?

[xDDunce]

I'm not sure on the differences between the types and what not, but the reason i got the error was because i put a "resb 16" in my code, which requests 16 bytes in the bss section. for some reason, the sections need to be sequential else in defined scopes. i was using elf at the time, so i think it may just be a section definition error (hence syntax error).

glad I'm worth something on these forums

Cheers,
James.

[brickhead20]

I don't mean to revive this thread, but just for the record, I would like to reinforce by example why this warning IS important. It caused a runtime bug in my code which took me a while to track down, because I hadn't noticed this warning.

My code had a "cli" instruction which appeared to do nothing, but after calling two "cli" instructions one after the other, they did. Adding a "nop" before a single "cli" fixed this, which without knowing about this warning was most puzzling.

Fixing this warning, fixed this bug as far as I know, because without finding the correct entry point, my code started one instruction later than intended (i.e. missed a "cli" instruction). This was not apparent as the rest of the code executed as normal, but interrupts fired afterwards (but could be masked a second cli instruction). This manifested as a double fault and an endless stream of general protection errors - on closer inspection of the error codes, if I recall, these were externally fired, but were an unnecessary pain to track down as this warning seems to have no apparent link with this bug.

Why?

I think perhaps either nasm or ld has changed at some point over the last year so that these symbols cannot be found as they were before. I haven't had the time to work on my code for a year or so, and if I remember, this code used to work. nm and objdump still show the symbols exist, but as, if I interpret correctly, of undefined type. Now they show as symbols of text type.

Lesson: Always look for, and fix warnings.

I hope this is useful for people having similar problems in the future!

Regards,
Richard