linker script headers

Hmmm, why not ask whoever specified that constraint? It's tough to guess without being familiar with the unspecified linker and knowing what is in the "header".

On a more general note, if it is simply a requirement for writing a linker control file, why not simply comply and not worry about it?

Thad

section

each of

Since I am about to teach on this subject, I should know how the thing works... The linker I am using is ld. Nobody seems to know why you should specify those program headers between loadable and unloadable sections.. the documentation of the linker is also very compact..

Tom

I assume you mean that the final memory map contains memory sections in the sequence data, bss, data(n), and not that you have to respecify the data section in your program modules. Similarly by loadable sections you are refering to RAM areas for all types of data and not holes in the memory map. But without a specific example of what you are refering to it is difficult to give complete answers, also to know what target environment and processor you are using.

This is a bit of a strange requirement, but I can see situations where this would be needed.

'ld' is used for lots of different target configurations, and I suspect you are only using it on a PC type environment.

I think you are forgetting how the program will run, when this distinction is crucial. You need to understand how your language runtime module works. Most applications only have one loadable section and one uninitialised section of data storage, so that the startup functions of your programme can copy the startup values and the 'uninitialised' sections are usually zeroed. Having a second section that needs to be loaded at startup means a more complex startup function.

If by loadable sections you are referring to where the programme AND data is stored, then the answer is quite simple that it all depends on the memory map of the target where different parts are in different types of memory at different address ranges, which may not be contiguous address ranges.

An example of what you are referring to and on what target platform/cpu would help elucidate what you question is about.

Ok, thanks for the information.

So usually there is only one loadable and one uninitialized section.

So the reason why you have to specify an extra header when you have a loadable section following an uninitialized section is the fact that you need a specific start address in your program headers to initialize those sections. Is that correct ?

In fact, those program headers are only used to set the start address of sections that have to be initialized (loadable sections) ?

Tom

the

map.

processor

What do *you* mean by 'loadable section'?

Please give an example of what you are having trouble understanding. Otherwise these suggestions of answers may NOT be what you are asking about.

ld assumes a loadable section as areas of memory for

programme data data reserved for initialising with start variables but stored elsewhere in memory (defined as NOLOAD but used as if it is)

Parts of the program will be split into different areas depending on the application and the target, ld is a general purpose linker for ALL types of target platforms PC to a single micro.

On a single micro you would need to know

Vectors Reset and interupt vectors text program code, constants, fixed data tables data Data that is initialised at startup bss Data that is zeroed at startup Special address that are referenced but not zeroed or initialised (e.g. a video capture frame buffer) Stack This is sometimes optional but is best defined for documentation.

On a PC application you don't have a vector table as that is under the operating system's control. So you normally only deal with text, data and bss, which may well be contiguous areas of memory.

On an embedded system ALL parts of the system have to be defined including in the linker script, which will exist in different parts of memory, some defined by the architecture (vector table), some by the target (size and location of ROM and RAM).

They give the start addresses of where to collect the parts from all your modules together. Do a test link and create a MAP file, examine the map file for results.

I am at the moment having trouble with the fact that you appear to not understand what linkers do and you are going to teach about a specific linker.

uninitialized

for

data

difficult

specify

distinction

works.

programme

usually

means

data

of

is)

of

bss,

file

Well, to my understanding, the linker takes the different object files. The sections in the different object files are put together in one object file. Those sections are loadable and others are not loadable.

For example; data, sdata, text, vectors... are sections that are loadable because they have to be loaded in the memory or they have to be initialized. Sections that are not loadable are uninitialized sections such as .bss, sbss.

The locater (inside the linker) assigns those sections to the memory location that you have specified in your linker script.

In my case I have the following linker script:

STACKSIZE = 1k;

STARTUP(boot.o) ENTRY(_boot)

MEMORY { bram1 : ORIGIN = 0xFFFF0000, LENGTH = 32k bram2 : ORIGIN = 0xFFFFC000, LENGTH = 16k }

PHDRS { hdr1 PT_LOAD; hdr2 PT_LOAD; hdr3 PT_LOAD; }

SECTIONS { .vectors : { *(.vectors) } > bram1 : hdr1

.text : { *(.text) } > bram2 : hdr2

.data : { *(.data) *(.got2) *(.fixup) *(.rodata) } > bram2

.sdata : { *(.sdata) } > bram2

.sdata2 : { *(.sdata2) } > bram2

.boot0 : { *(.boot0) } > bram2

.sbss : {

. = ALIGN(4); *(.sbss) . = ALIGN(4);

} > bram2

__sbss_start = ADDR(.sbss); __sbss_end = ADDR(.sbss) + SIZEOF(.sbss);

.bss : { . = ALIGN(4); *(.bss) *(COMMON) . = ALIGN(4); __bss_end = .;

. = . + STACKSIZE; . = ALIGN(16); __stack = .;

} > bram2

__bss_start = ADDR(.bss);

.boot 0xFFFFFFFC : { *(.boot) } > bram2 : hdr3 }

I need to specify those program headers because otherwise wrong program headers are generated. My question is: why does the vector, text and boot section need a different program header ? In fact i want to know how those program headers are used...

....

I assume both of these are RAM modules as no readonly sections specified.

Don't know why you need these.

Programme code loaded in final targets into ROM/Flash.

I would have expected this to be

.text : { *(.text) *(.rodata) } > bram2 : hdr2

I would normally expect .rodata to be after .text as both are READ-ONLY and for embedded applications would be static so in ROM.

I note that the 16K memory section has most of the sections and the 32K memory section ONLY contains the vectors. I would have expected anything that had fixed data (.text, .rodata, .boot and .vectors) to be in one MEMORY block which would be replaced by Flash/ROM on the end target, whilst .data, .bss, .sbss and .stack to be in RAM only sections.

These are target specific each target CPU has a specific reset vector to start executing from and the vector table at startup is in absolute address. Some processors support moving of the vector table after startup so at startup the startup code has fixed interupt vectors, and later the application or Operating System can used a RAM based one for its purposes. .boot section is target CPU specific to your processor which looks Motorola 68K derivative.

.text (and .rodata) is normally in separate memory area that will be programmed once i.e. ROM or FLASH memory, where as the data sections will be in RAM at different address as these are different devices.

Sections like .got2, .fixup, .sdata, .sdata2 and .boot0 appear to be related to your target CPU and possibly some libraries/operating system you are using.

You might find it easier if you used a consistent style in your script for the bss/sbss sections like:-

.sbss : { . = ALIGN(4); __sbss_start = .; *(.sbss) . = ALIGN(4); __sbss_end = .; } bram2

.bss : { . = ALIGN(4); __bss_start = .; *(.bss) *(COMMON) . = ALIGN(4); __bss_end = .;

. = . + STACKSIZE; . = ALIGN(16); __stack = .; } bram2