The issue was discovered here:
https://review.trustedfirmware.org/#/c/287/3/platform/ext/target/mps2/an519/gcc/mps2_an519_s.ld

We place section types on order here, but that also means the offset between .text and .rodata sections increases with each modification. Now if the .text section refers to these constants with an offset, sooner or later the offset might be too big. For example if an instruction has a 12 bit filed to encode relative offset to a constant then sooner or later we step out of the +-4k range. The linker might or might not be smart enough to replace the instruction to a different one.

Solution can be to place the .text and .rodata sections next to each other. It may also be worth to switch to a solution where we compile code to put specific type of content to dedicated segments (i.e. text_partition_x, .rodata_partition_x) and so on. The linker could have more freedom to place items as we could only say place any .*_partition_x into this section.

In case of ARMCLANG the .sct file simply refers to file(*.RO) (any read only content of as file), which covers .text and .rodata, hence they are placed next to each other.

Can we have a similar pattern with GCC?