linker script headers

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

Tom wrote:

> 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 ?

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

"Thad Smith" <thadsmith@acm.org> wrote in message
news:40BDEEFC.B45C615D@acm.org...
> Tom wrote:
>
> > 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 ?
>
> 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

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

On Thursday, in article <1086245172.217306@dmz2.imec.be>
     t_t_nospam1232000@yahoo.com "Tom" wrote:
>"Thad Smith" <thadsmith@acm.org> wrote in message
>news:40BDEEFC.B45C615D@acm.org...
>> Tom wrote:
>> > 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 ?

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. 

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

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

>those program headers between loadable and unloadable sections.. the
>documentation of the linker is also very compact..

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		| paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/>        Main Site
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
<http://www.badweb.org.uk/>             For those web sites you hate.

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



"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
news:20040603.0755.300109snz@pcserv.demon.co.uk...
> On Thursday, in article <1086245172.217306@dmz2.imec.be>
>      t_t_nospam1232000@yahoo.com "Tom" wrote:
> >"Thad Smith" <thadsmith@acm.org> wrote in message
> >news:40BDEEFC.B45C615D@acm.org...
> >> Tom wrote:
> >> > 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 ?
>
> 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.
>
> >> 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
> >
> >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
>
> 'ld' is used for lots of different target configurations, and I suspect
> you are only using it on a PC type environment.
>
> >those program headers between loadable and unloadable sections.. the
> >documentation of the linker is also very compact..
>
> 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 | paul@pcserv.demon.co.uk
> <http://www.pcserv.demon.co.uk/>        Main Site
> <http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
> <http://www.badweb.org.uk/>             For those web sites you hate.
>

On Thursday, in article <1086254761.604803@dmz2.imec.be>
     t_t_nospam1232000@yahoo.com "Tom" wrote:
>"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
>news:20040603.0755.300109snz@pcserv.demon.co.uk...
>> On Thursday, in article <1086245172.217306@dmz2.imec.be>
>>      t_t_nospam1232000@yahoo.com "Tom" wrote:
>> >"Thad Smith" <thadsmith@acm.org> wrote in message
>> >news:40BDEEFC.B45C615D@acm.org...
>> >> Tom wrote:
>> >> > 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 ?
>>
>> 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.
>>
>> >> 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
>> >
>> >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
>>
>> 'ld' is used for lots of different target configurations, and I suspect
>> you are only using it on a PC type environment.
>>
>> >those program headers between loadable and unloadable sections.. the
>> >documentation of the linker is also very compact..
>>
>> 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.

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)

>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 ?

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

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

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		| paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/>        Main Site
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
<http://www.badweb.org.uk/>             For those web sites you hate.

"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
news:20040603.1008.300117snz@pcserv.demon.co.uk...
> On Thursday, in article <1086254761.604803@dmz2.imec.be>
>      t_t_nospam1232000@yahoo.com "Tom" wrote:
> >"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
> >news:20040603.0755.300109snz@pcserv.demon.co.uk...
> >> On Thursday, in article <1086245172.217306@dmz2.imec.be>
> >>      t_t_nospam1232000@yahoo.com "Tom" wrote:
> >> >"Thad Smith" <thadsmith@acm.org> wrote in message
> >> >news:40BDEEFC.B45C615D@acm.org...
> >> >> Tom wrote:
> >> >> > 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 ?
> >>
> >> 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.
> >>
> >> >> 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
> >> >
> >> >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
> >>
> >> 'ld' is used for lots of different target configurations, and I suspect
> >> you are only using it on a PC type environment.
> >>
> >> >those program headers between loadable and unloadable sections.. the
> >> >documentation of the linker is also very compact..
> >>
> >> 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.
>
> 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)
>
> >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 ?
>
> 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).
>
> >In fact, those program headers are only used to set the start address of
> >sections that have to be initialized (loadable sections) ?
>
> 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.

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




>
> -- 
> Paul Carpenter | paul@pcserv.demon.co.uk
> <http://www.pcserv.demon.co.uk/>        Main Site
> <http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
> <http://www.badweb.org.uk/>             For those web sites you hate.
>

On Thursday, in article <1086265135.648052@dmz2.imec.be>
     t_t_nospam1232000@yahoo.com "Tom" wrote:
>"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
>news:20040603.1008.300117snz@pcserv.demon.co.uk...
>> On Thursday, in article <1086254761.604803@dmz2.imec.be>
>>      t_t_nospam1232000@yahoo.com "Tom" wrote:
......
>> >So usually there is only one loadable and one uninitialized section.
>>
>> 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.
....
>> 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.
>
>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
>}

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

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

Don't know why you need these.

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

Programme code loaded in final targets into ROM/Flash.

I would have expected this to be

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

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

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

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

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		| paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/         Main Site
<http://www.gnuh8.org.uk/               GNU H8 & mailing list info.
<http://www.badweb.org.uk/              For those web sites you hate.