sections, overview of their meaning?

sections, overview of their meaning?

[Torsten Mohr]

Hi,

there are lots of different sections in linker scripts, i know
some of them but there are quite many that i don't know.

Is there somewhere an overview on the sections and what is meant
to go into them?


Thanks for hints,
Torsten.

Re: sections, overview of their meaning?

[Nick Clifton]

Hi Torsten,

> there are lots of different sections in linker scripts, i know
> some of them but there are quite many that i don't know.
> 
> Is there somewhere an overview on the sections and what is meant
> to go into them?

Sorry no.  Sections can have arbitrary names and arbitrary contents, and 
there is no one single place where these names and contents are specified.

Some section names are commonly known and have a reasonably well defined 
purpose.  You probably know these names already.  eg: .text for code, 
.data for initialised, modifiable data, .bss for zero-initialised or 
uninitialised data, .rdata for non-modifiable data.

Other sections are often documented in the EABI for each particular 
processor.  So for example the ARM EABI describes sections called 
.ARM.exidx and .ARM.attributes.  (I tried to find a V850 based example, 
but I cannot find the ABI for this processor).

Otherwise the best guess is the name of the section itself.  Sometimes 
there will be comments in the linker script explaining what the section 
is for, but this is not always done.  For example the .zdata data 
section used by the V850 linker scripts is there for data that is 
accessed relative to r0 register, as hinted at by the "z" in the name, 
and the .rosdata section is for read-only data that is accessed via the 
global pointer register (r4), as hinted at by the definition of the __gp 
symbol in the .sdata section.

For sections that still mystify you please feel free to ask on this 
list, or search for references to them in the code for gas and gcc.

Cheers
   Nick

Re: sections, overview of their meaning?

[Torsten Mohr]

Hi Nick,

thanks a lot for your help, i really appreciate that.

I first tried to ask for an overview of sections because i
don't want to flood the group with questions about every section.
I want to make sure that every section in an own linker script
goes where it should go (ROM, RAM , ignored, ...).

Basically, i'd like to ask for nearly all sections in the
original V850 linker script, except the obvious ones like
.text, .data, .bss, ... .  What is ".dynamic" doing, what
are all the .rel* and .rela* for?
What about .ctors and .dtors?  They sound like C++ constructors
and destructors, but do they contain code (ROM) or data (RAM)
used in the constructors?


Would it make sense to set up an ordered list of the
sections with a description and a comment what platform(s)
it is used in?


Best regards,
Torsten.


> Hi Torsten,
>
> > there are lots of different sections in linker scripts, i know
> > some of them but there are quite many that i don't know.
> >
> > Is there somewhere an overview on the sections and what is meant
> > to go into them?
>
> Sorry no.  Sections can have arbitrary names and arbitrary contents, and
> there is no one single place where these names and contents are specified.
>
> Some section names are commonly known and have a reasonably well defined
> purpose.  You probably know these names already.  eg: .text for code,
> .data for initialised, modifiable data, .bss for zero-initialised or
> uninitialised data, .rdata for non-modifiable data.
>
> Other sections are often documented in the EABI for each particular
> processor.  So for example the ARM EABI describes sections called
> .ARM.exidx and .ARM.attributes.  (I tried to find a V850 based example,
> but I cannot find the ABI for this processor).
>
> Otherwise the best guess is the name of the section itself.  Sometimes
> there will be comments in the linker script explaining what the section
> is for, but this is not always done.  For example the .zdata data
> section used by the V850 linker scripts is there for data that is
> accessed relative to r0 register, as hinted at by the "z" in the name,
> and the .rosdata section is for read-only data that is accessed via the
> global pointer register (r4), as hinted at by the definition of the __gp
> symbol in the .sdata section.
>
> For sections that still mystify you please feel free to ask on this
> list, or search for references to them in the code for gas and gcc.
>
> Cheers
>    Nick

Re: sections, overview of their meaning?

[Ravi Ramaseshan]

Hi,

On 5/7/06, Torsten Mohr <tmohr@s.netic.de> wrote:
> Basically, i'd like to ask for nearly all sections in the
> original V850 linker script, except the obvious ones like
> .text, .data, .bss, ... .  What is ".dynamic" doing, what
> are all the .rel* and .rela* for?

The following document should give you the description of some of the
common sections including the .dynamic, .rel, .rela and others :
http://www.skyfree.org/linux/references/ELF_Format.pdf

> What about .ctors and .dtors?  They sound like C++ constructors
> and destructors, but do they contain code (ROM) or data (RAM)
> used in the constructors?

<quote: http://www.delorie.com/gnu/docs/gcc/gccint_149.html >
The best way to handle static constructors works only for object file
formats which provide arbitrarily-named sections. A section is set
aside for a list of constructors, and another for a list of
destructors. Traditionally these are called `.ctors' and `.dtors'.
Each object file that defines an initialization function also puts a
word in the constructor section to point to that function. The linker
accumulates all these words into one contiguous `.ctors' section.
Termination functions are handled similarly.
</quote>

Cheers,
--
Ravi Ramaseshan
http://www.geocities.com/ramaseshan_ravi/

" Reality is only something we believe in strongly. "

Re: sections, overview of their meaning?

[Torsten Mohr]

Hi,

thanks for these informations, it helped for .comment, .rel*
and other common parts.


Thanks,
Torsten.


> Hi,
>
> On 5/7/06, Torsten Mohr <tmohr@s.netic.de> wrote:
> > Basically, i'd like to ask for nearly all sections in the
> > original V850 linker script, except the obvious ones like
> > .text, .data, .bss, ... .  What is ".dynamic" doing, what
> > are all the .rel* and .rela* for?
>
> The following document should give you the description of some of the
> common sections including the .dynamic, .rel, .rela and others :
> http://www.skyfree.org/linux/references/ELF_Format.pdf
>
> > What about .ctors and .dtors?  They sound like C++ constructors
> > and destructors, but do they contain code (ROM) or data (RAM)
> > used in the constructors?
>
> <quote: http://www.delorie.com/gnu/docs/gcc/gccint_149.html >
> The best way to handle static constructors works only for object file
> formats which provide arbitrarily-named sections. A section is set
> aside for a list of constructors, and another for a list of
> destructors. Traditionally these are called `.ctors' and `.dtors'.
> Each object file that defines an initialization function also puts a
> word in the constructor section to point to that function. The linker
> accumulates all these words into one contiguous `.ctors' section.
> Termination functions are handled similarly.
> </quote>
>
> Cheers,
> --
> Ravi Ramaseshan
> http://www.geocities.com/ramaseshan_ravi/
>
> " Reality is only something we believe in strongly. "

Re: sections, overview of their meaning?

[Nick Clifton]

Hi Torsten,

> Basically, i'd like to ask for nearly all sections in the
> original V850 linker script, except the obvious ones like
> .text, .data, .bss, ... .  What is ".dynamic" doing, what
> are all the .rel* and .rela* for?
> What about .ctors and .dtors?  They sound like C++ constructors
> and destructors, but do they contain code (ROM) or data (RAM)
> used in the constructors?

Others have already answered your question, but I would just like to 
mention that just because a section appears in a linker script, that 
does not mean that it is used.  Any section in a linker script which 
does not match any sections in the input files to a particular link will 
not appear in the output of that link.

Quite often linker scripts are created by taking an already existing 
linker script and adding any extra section definitions needed by the 
particular target processor.  Since unused section descriptions make no 
difference to the linker's output they are just ignored, and so scripts 
can end up with quite a few section definitions that have no purpose but 
which can be quite baffling to anyone reading it.

Cheers
   Nick