What binary elf output format allows me to add a .sram section in my binary when linking? - compilation

Question

I am trying to compile an application using arm-none-eabi-gcc and would like specific section names to be contained in my binary. The binary is usually compiled by my IDE.
From the official GNU documentation:
SECTIONS { ...
secname : {
contents
}
... }
secname must meet the constraints of your output format. In formats which only support a limited number of sections, such as a.out, the name must be one of the names supported by the format (a.out, for example, allows only .text, .data or .bss).
The last sentence implies that depending on the output format you can have other or more sectionnames. The binary generated by my IDE contains amongst other things the following sections:
$ readelf -S TARGETBINARY.elf
There are 27 section headers, starting at offset 0x5335d8:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .sram PROGBITS 34000000 010000 053384 00 WAX 0 0 16
[ 2] .non_cacheable PROGBITS 34180000 070000 040000 00 WAX 0 0 256
[ 3] .ARM.exidx ARM_EXIDX 341c0000 0b0000 000008 00 AL 1 0 4
[ 4] .heap NOBITS 341c0008 0b0008 001000 00 WA 0 0 1
[ 5] .llce_boot_end PROGBITS 43840000 0b0008 000000 00 W 0 0 1
[ 6] .can_43_llce_shar PROGBITS 43800000 0b0008 000000 00 W 0 0 1
[ 7] .lin_43_llce_shar PROGBITS 4383d000 0b0008 000000 00 W 0 0 1
[ 8] .llce_meas_shared PROGBITS 4384ffe0 0b0008 000000 00 W 0 0 1
[ 9] .shareable_ram_bs PROGBITS 22c00000 0b0008 000000 00 W 0 0 1
[10] .shareable_ram_da PROGBITS 22c00000 0b0008 000000 00 W 0 0 1
[11] .debug_info PROGBITS 00000000 0b0008 12ade1 00 0 0 1
[12] .debug_abbrev PROGBITS 00000000 1dade9 01dceb 00 0 0 1
[13] .debug_aranges PROGBITS 00000000 1f8ad8 002848 00 0 0 8
[14] .debug_macro PROGBITS 00000000 1fb320 06d270 00 0 0 1
[15] .debug_line PROGBITS 00000000 268590 091d40 00 0 0 1
[16] .debug_str PROGBITS 00000000 2fa2d0 1a4bbc 01 MS 0 0 1
[17] .comment PROGBITS 00000000 49ee8c 000080 01 MS 0 0 1
[18] .ARM.attributes ARM_ATTRIBUTES 00000000 49ef0c 000037 00 0 0 1
[19] .debug_loc PROGBITS 00000000 49ef43 059247 00 0 0 1
[20] .debug_ranges PROGBITS 00000000 4f8190 0045a0 00 0 0 8
[21] .debug_frame PROGBITS 00000000 4fc730 00e310 00 0 0 4
[22] .stab PROGBITS 00000000 50aa40 00009c 0c 23 0 4
[23] .stabstr STRTAB 00000000 50aadc 00014d 00 0 0 1
[24] .symtab SYMTAB 00000000 50ac2c 017910 10 25 3938 4
[25] .strtab STRTAB 00000000 52253c 010f3e 00 0 0 1
[26] .shstrtab STRTAB 00000000 53347a 00015e 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
y (purecode), p (processor specific)
$
The generated binary info:
$file TARGETBINARY.elf
TARGETBINARY.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
Nothing fancy regarding file's output I guess...
As you can see this elf format does not for instance have a section named .bss, .text, etc... Instead it has amongst other things a .sram section, which is precisely what I want to have as well in my binary. Yet when I try to have a .sram section and no .bss section the linker tells me I am missing a .bss section. Which makes me believe I must be missing a linker option somehow...
This is my simplified linker script:
MEMORY
{
foo : ORIGIN = 0x22C00000, LENGTH = 0x00004000
}
SECTIONS
{
.sram :
{
__sram_bss_start = .;
*(.bss)
*(.bss*)
__sram_bss_end = .;
*(.text)
} > foo
}
This is the linker script used by my IDE: https://pastebin.com/c1JfXbY7
What option would allow me to have such .sram sections etc and no .bss nor .text section?
The GNU linker's documentation speaks about "--oformat=output-format" but there is not much info here about what possibilities there are for this option that could allow me to achieve what I meed here.
So I read all the relevant parts of the official documentation, but did not find anything usefull so far

Answer 1

As you can see this elf format does not for instance have a section named .bss, .text, etc... Instead it has amongst other things a .sram section, which is precisely what I want to have as well in my binary. Yet when I try to have a .sram section and no .bss section the linker tells me I am missing a .bss section. Which makes me believe I must be missing a linker option somehow...
Why do you want an .sram section versus a .bss? The simple solution is to use .bss. It is used by _start which is code that runs before main. The main routine needs all global and static variable to be set. There are two classes. 'Zero' variables as per .bss and initialized values. By default the _start implementation will look for a .bss section to initialize.
You don't say what libc your are using nor the compiler/linker options. If you insist on having just .sram, then you need to explore options like, -freestanding, -nostartfiles, and -nostdlib. By not having a .bss section you have broken some coupling between the standard library and the compiler/linker.
I think your real question is how to make a 'ram image' that you can program to ram without needing flash to be active as this is not supported by your IDE. There are various ways to this goal. You need to start by exploring the options above; especially -nostartfiles, which will require you to replace them. The other way is to provide the symbols that the linker wants. There is no reason not to name a section '.bss' and put it in RAM. The regions you have 'foo' is better name 'RAM' and you can put multiple section by using the '>RAM' linker syntax.
The options are enumerated in this answer.
Change the build options.
Provide the library.
Provide an alternative library.
Avoid the function call/data use
It would be difficult to avoid global and static data (but possible). You can define the symbols that the linker/startup wants. You haven't actually given an error message. It might be hidden by your 'IDE' which you might want to give details of. Eclipse based tools like 'Modus', STMCubeIDE, etc hide details like this from the developer.