Why is objcopy.exe altering the load addresses of some sections when a section is removed? - linker-scripts

Question

I am developing an application for an ARM Cortex-M3 device using the GCC toolchain. I have split the program memory into an application section and a configuration section by editing the linker script provided by the manufacturer of the device. The application section and configuration section each also have an associated CRC information section.
Sections which I have added are as follows:
.crc_info : CRC information for the application.
.glbl_cfg : Global configuration data.
.glbl_cfg_crc_info: CRC information for the global configuration data.
The linker script is a bit unusual because the flash memory is located at 0x60000000 and this is mapped to address 0x00000000 upon startup. Therefore, the linker script required for debugging has a load memory address (LMA) and virtual memory address (VMA) for flash memory sections. I presume that this ensures that the .elf is programmed to the correct memory area, but addressing is correct during run time. Here is an example of how this is done with the MEMORY and SECTIONS commands:
MEMORY
{
/* Global Configuration Memory */
cfg (rw) : ORIGIN = 0x6003F000, LENGTH = 2k - 8
/* Global Configuration Memory mirrored area.*/
cfgMirror (rw) : ORIGIN = 0x0003F000, LENGTH = 2k -8
}
SECTIONS
{
.glbl_cfg :
{
*(.app_cfg)
*(.app_cfg*)
} > cfgMirror AT>cfg
}
After compilation, here is the objdump.exe otuput:
arm-none-eabi-objdump.exe" -h file.elf
Sections:
Idx Name Size VMA LMA File off Algn
0 .vector_table 00000190 0000c000 6000c000 0000c000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .boot_code 00000570 0000c190 6000c190 0000c190 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .text 00004350 0000c700 6000c700 0000c700 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .data 00000030 20000100 60010a50 00020100 2**4
CONTENTS, ALLOC, LOAD, DATA
4 .crc_info 00000008 0001bff8 6001bff8 0002bff8 2**0
CONTENTS, ALLOC, LOAD, DATA
5 .glbl_cfg 00000010 0003f000 6003f000 0002f000 2**2
CONTENTS, ALLOC, LOAD, DATA
6 .glbl_cfg_crc_info 00000008 0003f7f8 6003f7f8 0002f7f8 2**0
CONTENTS, ALLOC, LOAD, DATA
7 .sharedRamNoInit 00000008 20000000 20000000 00010000 2**4
ALLOC
8 .bss 00000750 20000130 60010a80 00020130 2**4
ALLOC
9 .heap 0000e780 20000880 60010a80 00020880 2**4
ALLOC
10 .stack 00001000 2000f000 60010a80 0002f000 2**4
ALLOC
11 .debug_aranges 000008c0 00000000 00000000 0002f800 2**3
CONTENTS, READONLY, DEBUGGING
12 .debug_info 00014b1d 00000000 00000000 000300c0 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_abbrev 00002d62 00000000 00000000 00044bdd 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_line 00008119 00000000 00000000 0004793f 2**0
CONTENTS, READONLY, DEBUGGING
15 .debug_frame 000022d0 00000000 00000000 0004fa58 2**2
CONTENTS, READONLY, DEBUGGING
16 .debug_str 00016865 00000000 00000000 00051d28 2**0
CONTENTS, READONLY, DEBUGGING
17 .ARM.attributes 00000029 00000000 00000000 0006858d 2**0
CONTENTS, READONLY
18 .debug_ranges 00000890 00000000 00000000 000685b6 2**0
CONTENTS, READONLY, DEBUGGING
19 .debug_macro 000046f6 00000000 00000000 00068e46 2**0
CONTENTS, READONLY, DEBUGGING
20 .comment 00000066 00000000 00000000 0006d53c 2**0
CONTENTS, READONLY
And here is the output from readelf --segments:
arm-none-eabi-readelf.exe" --segments file.elf
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0x20000000 0x20000000 0x00000 0x00008 RW 0x10000
LOAD 0x00c000 0x0000c000 0x6000c000 0x04a50 0x04a50 R E 0x10000
LOAD 0x020100 0x20000100 0x60010a50 0x00030 0x00780 RW 0x10000
LOAD 0x020880 0x20000880 0x60010a80 0x00000 0x0e780 RW 0x10000
LOAD 0x02f000 0x2000f000 0x60010a80 0x00000 0x01000 RW 0x10000
LOAD 0x02bff8 0x0001bff8 0x6001bff8 0x00008 0x00008 RW 0x10000
LOAD 0x02f000 0x0003f000 0x6003f000 0x00010 0x00010 RW 0x10000
LOAD 0x02f7f8 0x0003f7f8 0x6003f7f8 0x00008 0x00008 RW 0x10000
Section to Segment mapping:
Segment Sections...
00 .sharedRamNoInit
01 .vector_table .boot_code .text
02 .data .bss
03 .heap
04 .stack
05 .crc_info
06 .glbl_cfg
07 .glbl_cfg_crc_info
This debugs and everything works as expected. However, I would also like to remove the .glbl_cfg and .glbl_cfg_crc_info sections from the elf file so that these are not always uploaded when debugging. The idea is to remove these sections without altering anything else, if this is even possible.
To do this I tried the following command and get the output shown.
arm-none-eabi-objcopy.exe" --remove-section=.glbl_cfg --remove-section=.glbl_cfg_crc_info file.elf file_noCfg
arm-none-eabi-objcopy.exe: file.elf: warning: empty loadable segment detected at vaddr=0x3f000, is this intentional?
arm-none-eabi-objcopy.exe: file.elf: warning: empty loadable segment detected at vaddr=0x3f7f8, is this intentional?
arm-none-eabi-objcopy.exe: file_noCfg.elf: section .heap lma 0x60010a80 adjusted to 0x600111d0
arm-none-eabi-objcopy.exe: file_noCfg.elf: section .stack lma 0x60010a80 adjusted to 0x6001f950
arm-none-eabi-objcopy.exe: file_noCfg.elf: section .crc_info lma 0x6001bff8 adjusted to 0x60020950
arm-none-eabi-objcopy.exe: file_noCfg.elf: section `.crc_info' can't be allocated in segment 3
LOAD: .bss .heap .stack .crc_info
There seems to be a problem with placing .crc_info in segment 3, but it was never in segment 3 in the first place.
Here is the objdump output of the new file:
arm-none-eabi-objdump.exe" -h file_noCfg.elf
Sections:
Idx Name Size VMA LMA File off Algn
0 .vector_table 00000190 0000c000 6000c000 0000c000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .boot_code 00000570 0000c190 6000c190 0000c190 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .text 00004350 0000c700 6000c700 0000c700 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .data 00000030 20000100 60010a50 00020100 2**4
CONTENTS, ALLOC, LOAD, DATA
4 .crc_info 00000008 0001bff8 60020950 00040950 2**0
CONTENTS, ALLOC, LOAD, DATA
5 .sharedRamNoInit 00000008 20000000 20000000 00010000 2**4
ALLOC
6 .bss 00000750 20000130 60010a80 00030130 2**4
ALLOC
7 .heap 0000e780 20000880 600111d0 00020130 2**4
ALLOC
8 .stack 00001000 2000f000 6001f950 00030130 2**4
ALLOC
9 .debug_aranges 000008c0 00000000 00000000 00040958 2**3
CONTENTS, READONLY, DEBUGGING
10 .debug_info 00014b1d 00000000 00000000 00041218 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_abbrev 00002d62 00000000 00000000 00055d35 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_line 00008119 00000000 00000000 00058a97 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_frame 000022d0 00000000 00000000 00060bb0 2**2
CONTENTS, READONLY, DEBUGGING
14 .debug_str 00016865 00000000 00000000 00062e80 2**0
CONTENTS, READONLY, DEBUGGING
15 .ARM.attributes 00000029 00000000 00000000 000796e5 2**0
CONTENTS, READONLY
16 .debug_ranges 00000890 00000000 00000000 0007970e 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_macro 000046f6 00000000 00000000 00079f9e 2**0
CONTENTS, READONLY, DEBUGGING
18 .comment 00000066 00000000 00000000 0007e694 2**0
CONTENTS, READONLY
As can be seen, the required sections have been removed, but some LMA addresses have been changed, including the LMA address of the .crc_info section. Generating a .hex file from file_noCfg.elf shows that the .crc_info section is indeed located at the address shown in the output above. This is a problem since the application's crc information will no longer be located where it is supposed to be.
Thank you for your patience, here is the main question and some related questions:
Why are section LMAs being changed when removing some sections?
Is objcopy supposed to move other sections around when removing sections, or have I made an error with generating some of the sections?
How do a get the behavior which I want (if possible)?