Re: Questions on arm-gcc linking: .ARM.exidx and .relocate sections

On 09/01/2025 09:47, pozz wrote:

I studied the output files from a build process of Atmel Studio project for SAMD20 MCU that is a Cortex-M0+.
The IDE uses arm-gcc compiler.
 The strange thing I noticed was the last Flash address used: in lss it is 2'06a4. Indeed lss file ends with:
 

.ARM.exidx      0x000206a4        0x8
  *(.ARM.exidx* .gnu.linkonce.armexidx.*)
  .ARM.exidx     0x000206a4        0x8 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/thumb/v6-m\libgcc.a(_udivmoddi4.o)
                 [!provide]                PROVIDE (__exidx_end, .)

This shows that the ".ARM.exidx" section is being pulled in by the code for the "_udivmoddi4.o" object file in libgcc.a.  _udivmoddi4 is a function that does division and modulo of 64-bit unsigned integers (on targets that don't have a matching hardware instruction).  But since it is a "linkonce" section, it could also be pulled in by many other functions - "linkonce" sections get merged automatically.
My understanding is that this section and the following few bytes are required for stack unwinding for C++ exceptions.  Even if you are not using C++, or using it with exceptions disabled, there is still a very small amount of such data generated and included in the C library builds, because someone might call these functions in combination with C++ exceptions.  It is, I would say, too small to worry about in all but the tightest memory situations.

  However I noticed another strange thing. The hex file that I use for production doesn't end at address 2'06AC, but at address 2'08CC. There are other 0x220=544 bytes.
  After exploring the output files I found the .relocate sections in map file. It seems it is linked to RAM (0x2000'0000):
  .relocate       0x20000000      0x220 load address 0x000206ac
                 0x20000000                . = ALIGN (0x4)
                 0x20000000                _srelocate = .
  *(.ramfunc .ramfunc.*)
  *(.data .data.*)
  .data.memset_func
                 0x20000000        0x4 src/mbedtls/library/platform_util.o
  .data.g_interrupt_enabled
                 0x20000004        0x1 src/ports/samd20/ASF/common/utils/interrupt/interrupt_sam_nvic.o
                 0x20000004                g_interrupt_enabled

<snip>

                 0x20000220                _erelocate = .
 .bss            0x20000220     0x611c load address 0x000208d0
                 0x20000220                . = ALIGN (0x4)
                 0x20000220                _sbss = .
                 0x20000220                _szero = .
  However I think it is linked in Flash and copied in RAM during startup code.

Yes.

  From what I understand, they are global/static variables initialized in the declaration (with a startup value).
 

Yes, that is exactly what it is.
Uninitialised file-scope and static data in C goes in the ".bss" section, linked to ram.  There is code in the crt.o file (or another startup file) that clears the .bss to zero.
Initialised file-scope and static data goes in the ".data" section. This is linked to ram (i.e., the addresses of the variables are in ram) but there is also a copy in flash with the initialisation data.  The pre-main startup code copies the data from flash to the .data section.
It is also possible to link functions to ram - they are copied across in the same way (that's the ".ramfunc" section mentioned in your map file).   You might do this for speed-critical code on a microcontroller with slow flash, or for functions used by flash programming routines.