1

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

zupoluzu
  • 51
  • 4
  • Because it defines the symbols `__sram_bss_start` and `__sram_bss_end` or the derived symbols `__BSS_SRAM_START`, etc. Some '.o' file refers to these symbols and you get a link failure because you did not define them. See: [Gnu ld LMA](https://sourceware.org/binutils/docs/ld/Output-Section-LMA.html).. `_bstart` and `_bend` are defined in the linker file. These are the same type of symbols that some code you are linking with has. – artless noise Dec 12 '22 at 22:39
  • There are many other definitions __BSS_SRAM_START, __BSS_SRAM_SIZE , etc. You have not duplicated everything. I don't have the tools so I can only guess (as I have said many times). *the linker tells me I am missing a .bss section* What is exact text message, typed out? – artless noise Dec 13 '22 at 11:14
  • Is this the message *error: no memory region specified for loadable section `.bss'*? That is referring to the section attributes. You need to say the RAM is loadable (ie, there is something that is going to program it). The linker file has attributes for sections. For instance 'ROM' is not a place you can put data. – artless noise Dec 13 '22 at 11:26

1 Answers1

0

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.

  1. Change the build options.
  2. Provide the library.
  3. Provide an alternative library.
  4. 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.

artless noise
  • 21,212
  • 6
  • 68
  • 105
  • An image with an 'sram' section doesn't mean it will work in RAM. Why do you believe this? If some tool/bootloader document told you this, then the documentation to that tool/bootloader is very important to answer your question. – artless noise Dec 12 '22 at 21:17