how to use the linker scripts?

[McZ]

I have seen some different linker scripts but when I try to use them I find they generate different types of errors or the output image file doesn't work to boot..

I'm using Nasm and gcc that comes along with slackware 10.0

any help/tutorials on this topic?

[Solar]

Could you be more specific as to what linker script you used, what your compiler / linker command lines were, what your code looked like?

[Pype.Clicker]

http://www.osdev.org/osfaq2/index.php/BareBones gives you a really minimalistic (that works)

[McZ]

thank you for your answers, sorry that I havn't been able to write down my own script/code etc.

I'll try the linker script as soon as I get home and can try it.

if someone could be nice to explain what the linker-script does (or give me a link to a good tutorial or something) it would be good, I havn't found anyone that I understand correct yet.

if it has anything to do with all this I'm using nasm and gcc in slackware 10.0.

[Solar]

if someone could be nice to explain what the linker-script does (or give me a link to a good tutorial or something) it would be good, I havn't found anyone that I understand correct yet.

Which means your idea of what a linker does is fuzzy, and your idea of how an executable is constructed is virtually non-existent.

Every object file (C code turned into machine code but not yet linked together) is constructed of several sections. For example, executable code in *.text, constants in *.rodata, initialized variables in *.data, global variables in *COMMON, zero-initialized memory in *.bss.

If you followed Pype's link into the FAQ, you'll see a pattern here.

What those sections are depends on the object file format (ELF, COFF, PE, etc.). The FAQ assumes ELF.

The linker script tells the linker how to put the individual object files' sections together into a single binary: *.text and *.rodata into *.text, *.data into *.data, *COMMON and *.bss into *.bss. Again, this pattern is dependent on the binary file format (which, again, we assume is ELF).

The rest is telling the linker what symbol designates the entry point (_loader), and where the resulting binary will be loaded to (0x00100000) so it can adapt any memory references.

Voila, your object files have been linked together into a binary.

Usually, when compiling application software, you don't specify a linker script, you use the default one - which links in the C runtime (crt0.o) and loads of auxiliary stuff you wouldn't want in your kernel image. That's why you have to juggle linker scripts when linking a kernel.

That's what our example script does, which is sufficient to get you started.

As to what else you can do in a linker script, refer to the ld manual (part of binutils, http://www.gnu.org/software/binutils/manual/). As to object file format details, refer to the individual format descriptions, or reverse-engineer 'em with objdump if you feel adventurous.

[Pype.Clicker]

The "executable file format hacker toolbox" consist of
- "official" documentation, which you can easily get on wotsit.org
- the objdump program, showing a pretty-print version of the binary content, for instance:

Code: Select all

pype/C32> objdump -h kernel/bin/kernel.elf 

kernel/bin/kernel.elf:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00023a40  00000000  00000000  00000080  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         000125d0  00023a40  00023a40  00023ac0  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00001580  00036010  00036010  00036090  2**5
                  ALLOC
  3 .comment      00000805  00000000  00000000  00036090  2**0
                  CONTENTS, READONLY
  4 .note         00000460  00000000  00000000  00036895  2**0
                  CONTENTS, READONLY

- an hexadecimal viewer (hexdump is usually available on unix machines)
- a printed copy of "Linkers and Loaders" book ...

Note that if you type "info ld" on a correctly installed unix system, you're quite close from a description of the linker scripts:

Every link is controlled by a "linker script". This script is
written in the linker command language.

The main purpose of the linker script is to describe how the
sections in the input files should be mapped into the output file, and
to control the memory layout of the output file. Most linker scripts
do nothing more than this. However, when necessary, the linker script
can also direct the linker to perform many other operations, using the
commands described below.

(...)


* Menu:

* Basic Script Concepts:: Basic Linker Script Concepts
* Script Format:: Linker Script Format
* Simple Example:: Simple Linker Script Example
* Simple Commands:: Simple Linker Script Commands
* Assignments:: Assigning Values to Symbols
* SECTIONS:: SECTIONS Command
* MEMORY:: MEMORY Command
* PHDRS:: PHDRS Command
* VERSION:: VERSION Command
* Expressions:: Expressions in Linker Scripts
* Implicit Linker Scripts:: Implicit Linker Scripts

[McZ]

Which means your idea of what a linker does is fuzzy, and your idea of how an executable is constructed is virtually non-existent.

erhm... ::) well I do know that there is different sections for text, data etc. when code is compiled, but I still can't figure out how to make a linker script for my own code and why?

and then another thing, should my bootsector and/or second stage use a linker script or do I only need one for my kernel image?

[Pype.Clicker]

Your bootsector is likely to be written in ASM, in a single file. So you probably have more control about what's being generated (using align, org, etc) than with a linker script. Just assemble it into a binary file and voil? ...

Same remark for the second-stage loader ...

[Solar]

I still can't figure out how to make a linker script for my own code and why?

As I said, the default linker script for application space programming does several things you don't want in kernel space. For example, it assumes your entry point is _main.

That's the "why". The "how" is in the binutils manual (or issue an 'info ld' and jump to chapter 3, "Linker Scripts".

[Dreamsmith]

Usually, when compiling application software, you don't specify a linker script, you use the default one - which links in the C runtime (crt0.o) and loads of auxiliary stuff you wouldn't want in your kernel image. That's why you have to juggle linker scripts when linking a kernel.

Actually, it's not true that you have to juggle linker scripts when linking a kernel. All you need to do is specify the correct command line options while linking, and the default linker works just fine.

As I said, the default linker script for application space programming does several things you don't want in kernel space. For example, it assumes your entry point is _main.

Assuming you forget to use the "-e" flag, which sets your entry point. Here's what ld gets from my Makefile:

Code: Select all

ld -s -static -nostdlib -Ttext 0x108100 -e setup $^ -o $@

Can you get better control than this using a linker script? Certainly. Do you need to? Probably not.

[Pype.Clicker]

Linker scripts can become necessary if you wish to define symbols like __start_of_code or __end_of_kernel, __start_of_bss_section_that _you_have_to_wipe, etc.

It also gives you better control about sections merging (esp. useful if you're writing your own loader and don't want to mess up with .rodata.str.32 and things alike ...), about alignment and padding, etc.

[Dreamsmith]

Linker scripts can become necessary if you wish to define symbols like __start_of_code or __end_of_kernel, __start_of_bss_section_that _you_have_to_wipe, etc.

True, but defining such symbols is not necessary -- all this information is available in your ELF program headers if you're using the default linker scripts.

It also gives you better control about sections merging (esp. useful if you're writing your own loader and don't want to mess up with .rodata.str.32 and things alike ...), about alignment and padding, etc.

Sure. Not saying there's no reason to do it, I was just objecting to Solar's assertion that it was necessary. If you're intending to go the ELF route, I would assert it's not even desirable. The default linker scripts work just fine for an ELF-based system, and do all the right things vis a vie alignment and so on.

Anyone doing the kinds of things you're suggesting above has a fairly sophisticated understanding of the program assembly process and can understand linker scripts fairly easily. But it's a confusing and unnecessary detail to throw at newbies. The last thing we should tell a newbie is that they need or even ought to have a linker script. The "bare-bones" section of the Wiki ought not to have a linker script, since it's definately not necessary in any "bare-bones" kernel.