linker script headers

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

Can anyone explain me the following statement:
If a memory that contains loadable section followed by uninitialized section
followed by another loadable
section then in this case the memory region needs 2 headers (one for each of
the loadable memory chunk).
Why is this ?

Tom



Re: linker script headers

Quoted text here. Click to load it

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

Re: linker script headers

Quoted text here. Click to load it
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



Re: linker script headers
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

--
Paul Carpenter        | snipped-for-privacy@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/ Main Site
We've slightly trimmed the long signature. Click to see the full one.
Re: linker script headers
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



Quoted text here. Click to load it
the
map.
processor



Re: linker script headers
Quoted text here. Click to load it


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)

Quoted text here. Click to load it

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).

Quoted text here. Click to load it

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.

--
Paul Carpenter        | snipped-for-privacy@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/ Main Site
We've slightly trimmed the long signature. Click to see the full one.
Re: linker script headers

Quoted text here. Click to load it
uninitialized
for
data
difficult
specify
distinction
works.
programme
usually
means
data
of
is)
Quoted text here. Click to load it
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...




Quoted text here. Click to load it



Re: linker script headers
Quoted text here. Click to load it
......
....

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

Quoted text here. Click to load it

Don't know why you need these.

Quoted text here. Click to load it

Programme code loaded in final targets into ROM/Flash.

I would have expected this to be

  .text : { *(.text) *(.rodata) } > bram2 : hdr2
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

--
Paul Carpenter        | snipped-for-privacy@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/ Main Site
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline