I have been reading the sections documentation for ld and something isn't clear.
Given the partial linker script:
MEMORY
{
FLASH1 (rx) : ORIGIN = 0x000FB000, LENGTH = 0x05000
FLASH2 (r) : ORIGIN = 0x000FA000, LENGTH = 0x01000
}
SECTIONS
{
.some_code :
{
KEEP(*(SORT(.some_code*)))
} > FLASH1
}
SECTIONS
{
.my_page :
{
KEEP(*(SORT(.my_page*)))
} > FLASH2
}
Is there ever a reason to have 2 section commands in a single linker script as above rather than having it all in 1 section commands as below?
SECTIONS
{
.some_code :
{
KEEP(*(SORT(.some_code*)))
} > FLASH1
.my_page :
{
KEEP(*(SORT(.my_page*)))
} > FLASH2
}
Or are they equivalent. Are there other cases where you'd want to split it up like that?
Additional clarification: I am asking for a reason to have separate "SECTIONS" commands (each with their own block of section definitions) not asking for the reason for having separate sections in general.
The SECTIONS command tells the linker how to map input sections into output sections, and how to place the output sections in memory. The format of the SECTIONS command is: SECTIONS { sections-command sections-command … }
A linker script controls every link. Such a 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.
Linker command files allow you to put linker options and directives in a file; this is useful when you invoke the linker often with the same options and directives. Linker command files are also useful because they allow you to use the MEMORY and SECTIONS directives to customize your application.
There isn't ever an unavoidable need to write more than one SECTIONS
command,
or MEMORY
command, in a linker script.
SECTIONS
{
/* Commands... */
}
SECTIONS
{
/* More commands... */
}
is equivalent to:
SECTIONS
{
/* Commands... */
/* More commands... */
}
and likewise for MEMORY
.
However, the maintainability of a non-trivial body of linker-scripts is
assisted if a linker script can include multiple SECTIONS
or MEMORY
commands. E.g. if:
foobar.lds (1)
MEMORY
{
FOOMEM (rx) : ORIGIN = 0x000FB000, LENGTH = 0x05000
BARMEM (r) : ORIGIN = 0x000FA000, LENGTH = 0x01000
}
SECTIONS
{
.foo : {
*(.foo)
} > FOOMEM
.bar : {
*(.bar)
} > BARMEM
}
were something much less trivial than it is, it might be better refactored as:
foobar.lds (2)
INCLUDE ./foo.lds
INCLUDE ./bar.lds
foo.lds
MEMORY
{
FOOMEM (rx) : ORIGIN = 0x000FB000, LENGTH = 0x05000
}
SECTIONS
{
.foo : {
*(.foo)
} > FOOMEM
}
bar.lds
MEMORY
{
BARMEM (r) : ORIGIN = 0x000FA000, LENGTH = 0x01000
}
SECTIONS
{
.bar : {
*(.bar)
} > BARMEM
}
so that foobar.lds
(2) is expanded by the linker to
foobar.lds (3)
MEMORY
{
FOOMEM (rx) : ORIGIN = 0x000FB000, LENGTH = 0x05000
}
SECTIONS
{
.foo : {
*(.foo)
} > FOOMEM
}
MEMORY
{
BARMEM (r) : ORIGIN = 0x000FA000, LENGTH = 0x01000
}
SECTIONS
{
.bar : {
*(.bar)
} > BARMEM
}
An historical note: In this obselete GNU ld
manual from bygone days,
we can find the constraints:
You may use at most one SECTIONS command in a script file, but you can have as many statements within it as you wish.
and:
A command file may contain at most one use of the MEMORY command; however, you can define as many blocks of memory within it as you wish.
which are absent from the current manual.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With