We have a linker script with a custom section that was added for some IEC compliance test reasons. However, ever since adding this section the binary size created via objcopy -O binary input output
has exploded from ~150kbytes to ~ 512Mbytes.
I've traced it down to the section missing the (NOLOAD)
attribute. And I also can somewhat reason on why the binary was 512Mbytes.
Our memory is as follows:
MEMORY
{
rom (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00007580
CUSTOM_SECTION (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00001000
}
The section as originally defined is:
CUSTOM_LOCATION:
{
CUSTOM_BEGIN = .;
KEEP(*(CUSTOM_LOCATION));
CUSTOM_END = .;
} > CUSTOM_SECTION AT > ram
If CUSTOM_LOCATION:
is replaced with CUSTOM_LOCATION (NOLOAD):
the generated binary is of normal sice. Without the (NOLOAD)
the binary size is ~512Mbytes.
I am looking for the reason why this binary becomes so large. What does (NOLOAD)
(or the absence of it) mean for objcopy
in generating a binary file?
Secondary question, at the end of the section we say } > CUSTOM_SECTION AT > ram
can we do without this directive? Can it just be replaced with } > ram
? (And this can I remove the CUSTOM_SECTION
from the MEMORY
part?
I've seen no differences in the generated map
file