Linker Script Entry Point

[brodeur235]

I am new to linker scripts and I know this will sound like a super simple problem that should be googled, but I have read the ld manual and done exactly what one kernel dev tut does and still I get the same warning:

Code: Select all

ld: warning: cannot find entry symbol start; not setting start address

Even though I have this in one of my two object files (both flat binaries) that are being linked:

Code: Select all

[bits 32]
global start
start:
mov eax,0x00000001

Here is my linker script:

Code: Select all

TARGET("binary")
OUTPUT_FORMAT("binary")
ENTRY(start)

SECTIONS
{
	. = 0x00000000;
	.text : { *(.text) }
	.data : { *(.data) }
	.bss : { *(.bss) }
}

Help appreciated,

Brodeur235

[Combuster]

Why are you specifying an entry point at all? A flat binary has no header to put that...

[neon]

Even though I have this in one of my two object files (both flat binaries) that are being linked:

Flat binaries are just that - flat binaries. They do not contain any symbolic information to link with [Thus is not possible to link and thus both a linker and entry point symbol will not work. This also means you specifying the sections .text, .bss and .data in your linker script is pretty useless]

The entry point of a flat binary can be anywhere depending on what called it. In most cases, its just at the first byte in the binary (..which is the top of your primary source file.)

[brodeur235]

learning that binaries can't have symbols, I assembled the input object files to elf instead of binary, and then linked, like this:

Code: Select all

nick@nicks-ubuntu-laptop:~/Desktop$ nasm f1.asm -f elf -o f1.o
nick@nicks-ubuntu-laptop:~/Desktop$ nasm f2.asm -f elf -o f2.o
nick@nicks-ubuntu-laptop:~/Desktop$ ld f1.o f2.o -T linker.ld
ld: warning: cannot find entry symbol start; defaulting to 0000000000000000

Obviously I'm still getting a warning... This one is different though; at least it's defaulting the start address to 0 instead of not setting it, as before.

The linker script is still pretty much the same. All that's different is that it's without the target("binary") line now.

Brodeur235

[NickJohnson]

But it really doesn't matter - there is no entry point in a flat binary, so it also doesn't matter if the linker sets it to 0. Additionally, there is no symbol table, which is why the linker can't find the symbol "start".

Edit: You should try making NASM output flat binary instead of ELF

[Combuster]

You are using a 64 bit linux kernel, right? Your toolchain seems to think it needs to make 64 bit binaries.

GCC Cross-Compiler

[kop99]

I think that the similar problem posted before.
You would get some help following.

http://forum.osdev.org/viewtopic.php?f= ... rt#p157893

[brodeur235]

But it really doesn't matter - there is no entry point in a flat binary, so it also doesn't matter if the linker sets it to 0.

Yes... BUT, which object file's code is at 0. Several object files were all linked together; the linker then squishes all the object file's code together. Which object file's code comes first? The first specified on the command line? That would make sense, but it's just a blind guess.

Additionally, there is no symbol table, which is why the linker can't find the symbol "start".

First time I'm hearing this... Interesting.

Edit: You should try making NASM output flat binary instead of ELF

I have been doing this... I switched to other formats (elf/aout) to support symbols in nasms output.

I have a feeling I'm not going about what I'm trying to do the right way. My knowledge of assemblers and linkers is obviously very limited, so let me tell you what I'm trying to do: Up until now I have been writing my OS (boot loader AND kernel) in one single asm file. The file is now over 3000 lines long and although I have organized and commented the file extensively, I want to modularize it now (I think that's a verb... I get no spell check error). Up until now, I have been simply assembling this single asm file like so: nasm os.asm -f bin -o os.img and booting from that floppy image via multiple emulators. A (very) simple example or explanation of how I could do this would be appreciated. I want, for example, to be able to put my k_mem functions in a different file than my k_put_* for organizational benefits and until now the obscurities of a linker and different object file types (other than flat binary) have avoided me. What is the best thing to do?

Brodeur235

[neon]

Yes... BUT, which object file's code is at 0. Several object files were all linked together; the linker then squishes all the object file's code together. Which object file's code comes first? The first specified on the command line? That would make sense, but it's just a blind guess.

Object files are never "squished" together. They are linked together into a different file, the output file. The first object file comes first.

Additionally, there is no symbol table, which is why the linker can't find the symbol "start".

First time I'm hearing this... Interesting.

That is what is meant by binary files having no symbolic information.

Edit: You should try making NASM output flat binary instead of ELF

I have been doing this... I switched to other formats (elf/aout) to support symbols in nasms output.

Why are you working with flat binaries then? Flat binaries are very different then elf/aout formats, as they contain a structure to the file, a flat binary does not.

What is the best thing to do?

Follow what most boot loaders do. Have the boot code a flat binary and have it load and parse either a startup program (aka, "2nd stage boot loader"), or the kernel file directly. This is my recommendation, anyways.

[manonthemoon]

I have a feeling I'm not going about what I'm trying to do the right way. My knowledge of assemblers and linkers is obviously very limited ..... and until now the obscurities of a linker and different object file types (other than flat binary) have avoided me.

You should definitely get a firm grasp of your tools before getting too far in your OS. I would hardly consider a linker or an ELF file to be an obscurity. There are a lot of tools and they all have many features, some of which are very useful, and others surprising (which leads to frustration!). The sooner you learn to use them effectively, the less time you'll waste messing around with files and formats. There are wiki pages on this site that explain all the different tools. Start with Linkers.

For organization and project management, look into the "make" command. You will need it once your project grows larger. There is a wiki page on Makefiles here. Essentially, a makefile allows you to build your entire project with one simple command, like "make os.img", and it takes care of assembling the individual files and linking them. Of course, you have to write the makefile yourself in order for this to happen.

A (very) simple example or explanation of how I could do this would be appreciated. I want, for example, to be able to put my k_mem functions in a different file than my k_put_* for organizational benefits

Assemble each separate file into a separate ELF object, so you'll have for example, mem.o, init.o, screen.o, etc. Then use your linker to combine all the objects into a single file. If you're going to use that file directly as your floppy image, it needs to be a flat binary or else the ELF header will interfere as part of your boot loader.

[brodeur235]

Thanks, you guys have been helpful. I've got it working now,

Brodeur235