Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32309

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

Show all headers | View raw

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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Questions on arm-gcc linking: .ARM.exidx and .relocate sections pozz <pozzugno@gmail.com> - 2025-01-09 09:47 +0100
  Re: Questions on arm-gcc linking: .ARM.exidx and .relocate sections David Brown <david.brown@hesbynett.no> - 2025-01-09 13:44 +0100
    Re: Questions on arm-gcc linking: .ARM.exidx and .relocate sections pozz <pozzugno@gmail.com> - 2025-01-09 22:28 +0100
      Re: Questions on arm-gcc linking: .ARM.exidx and .relocate sections David Brown <david.brown@hesbynett.no> - 2025-01-10 11:03 +0100

csiph-web