Generated binary file from elf file explodes if NOLOAD is removed from section

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

When objcopy creates a binary file it basically does the same job as the OS ELF loader: it writes the loadable ELF file sections into a file that represents the memory at run-time.

The binary file will contain every byte of your code and data, from the base address to the uppermost byte. If the memory image is sparse (there are areas of "nothing"), then the binary file will also contains large areas of nothing. This can only be represented in a dumb binary file as zeros.

Your elf file has data from address 0x00000000 (the base of ROM), to 0x20000fff (the top of CUSTOM_SECTION), which is a range of just over 500MB, so it stands to reason that the binary file must have that many bytes to hold it all. By making the section non-loadable you're saying that the data is not needed at run-time and therefore need not be in the binary image. This is normally the case for debug information, comments, and other non-program ELF data.

The good news is that a) many file-systems will only use disk space for the non-zero portions of the file, so it doesn't use as much disk as it appears (a "sparse file"), and b) the binary will be readily compressible.