Atollic Truestudio ELF output file - segment starts from wrong address

I'm developing my custom bootloader for STM32 microcontrollers (e.g., STM32F072). It uses its own firmware file format, so I need to develop a tool to convert firmware file produced by compiler and linker.

My bootloader is placed in FLASH from address 0x08000000, and the area for user application starts from 0x08006000. The first 0x100 bytes of RAM are used by the bootloader for application's vector table relocation.

I build the user application in Atollic Truestudio for STM32 version 9.1.0. By default (when I just create a project with STM32CubeMX), .ld file contains memory areas definitions:

RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 16K
FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 64K

and the resulting ELF file's program header is:

>arm-atollic-eabi-objdump -p f072.elf

f072.elf:     file format elf32-littlearm

Program Header:
    LOAD off    0x00010000 vaddr 0x08000000 paddr 0x08000000 align 2**16
         filesz 0x00002ee0 memsz 0x00002ee0 flags rwx
    LOAD off    0x00020000 vaddr 0x20000000 paddr 0x08002ee0 align 2**16
         filesz 0x00000158 memsz 0x000011f8 flags rw-
    LOAD off    0x000211f8 vaddr 0x200011f8 paddr 0x08003038 align 2**16
         filesz 0x00000000 memsz 0x00000600 flags rw-
private flags = 5000200: [Version5 EABI] [soft-float ABI]

All looks OK. When I redefine memory area to build project for using with bootloader:

RAM (xrw)       : ORIGIN = 0x20000100, LENGTH = 0x3f00
FLASH (rx)      : ORIGIN = 0x08006000, LENGTH = 40K

the resulting ELF file's program header is:

Program Header:
    LOAD off    0x00000000 vaddr 0x08000000 paddr 0x08000000 align 2**16
         filesz 0x00008ee0 memsz 0x00008ee0 flags rwx
    LOAD off    0x00010100 vaddr 0x20000100 paddr 0x08008ee0 align 2**16
         filesz 0x00000158 memsz 0x000011f8 flags rw-
    LOAD off    0x000112f8 vaddr 0x200012f8 paddr 0x08009038 align 2**16
         filesz 0x00000000 memsz 0x00000600 flags rw-

The base address of code segment did not change as I expected, but its size is increased by 0x6000 (equal to the difference between new and old base addresses of memory area in linker script).

So, if my converter will parse only program header (and not sections), it could not detect that program actually begins from address 0x08006000.

Also, when I use STM32CubeProgrammer and try to open this ELF file, it does not recognize that there are no code or data from address 0x08000000 to 0x08006000, and show in its log:

Segment[0]: address= 0x8000000, size= 0x9038

When I convert the ELF file to binary it is OK (there are no "extra" 0x6000 bytes in the beginning), but I want to use ELF file because in this case I can check that program is linked correctly for using with bootloader. Of course, I can parse section headers, but I want to understand what is going with the program header first.

So, my questions:

1) Why does the linker produce such a program header in output ELF file? Is it a linker's bug, result of incorrect usage or a normal and documented linker's behavior?

2) Is there any command-line argument or linker script directive to make the linker write actual base address (0x08006000 in my case) to VADDR and PADDR fields program header's code segment record?