(arm-none-eabi-gcc) creating .elf binary from bootloader + 2 x firmware image

I'm developing for a STM32F429 with CLion and trying to create a merged .elf file from three .elf files.The layout of the merged .elf file should look like this:

• Bootloader.elf (maximum 256K, but can vary in size)
• FirmwareImage.elf (always 384K, fills up allotted space for 1st firmware image)
• FirmwareImage.elf (always 384K, fills up allotted space for 2nd firmware image)

This makes 1M exactly in total.

I've tried to converting the .elf files to .bin (with arm-none-eabi-objcopy) and creating a 1M .bin file with a custom tool I wrote. I can confirm the layout of the .bin this creates is correct. I then convert the generated .bin file back to .elf with:

arm-none-eabi-objcopy -I binary -O elf32-little --change-section-address .data=0x08000000 in.bin out.elf

The data section address change is to reflect the start of flash memory in the STM32F429.

When I try to flash this file using openocd, it fails with:

Error: invalid ELF file, no program headers

Is there a way of skipping the .elfs -> .bin -> .elf conversion and go directly from .elfs -> .elf? Or otherwise, insert the program headers? I doubt these are actually used during flashing.

I know I could tell openocd to use the generated .bin file directly by specifing the flash address. But CLion won't let openocd flash .bin files from its arm-embedded plugin, only .elf files.

Edit:At the moment I'm using these linker scripts, adapted from ST's official one. There is quite a bit going on in them.I might just be able to use a single linker script to achieve this. I could have the following code:

extern "C" __attribute__((__section__(".bootloader"))) void runBootloader(){    Platform platform;    DFUBootloader bootloader(platform);}extern "C" __attribute__((__section__(".image1"))) void runApplication1(){    Platform platform;    Application application(platform);}extern "C" __attribute__((__section__(".image2"))) void runApplication2(){    Platform platform;    Application application(platform);}

If these linker places these symbols at the right locations, would the symbols used by them end up in the correct place as well? The firmware image has to be duplicated to fill up both firmware pages, so all the symbols used by the application as well have to be duplicated.