Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32310

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

Show all headers | View raw

Il 09/01/2025 13:44, David Brown ha scritto:
> 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.

Ok, but what are those 8 bytes? Code? Values? It is strange there aren't 
any info in lss.


> 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.  

Thanks for the explanation that I take as is, without fully 
understanding :-)

> It is, I would say, too small to worry about in all but 
> the tightest memory situations.

Of course, yes. My question was "What is it?", not "How to save these 8 
bytes?" if I don't need it.


>> 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.

I expected to see the non volatile copy in Flash of .relocate in the map 
file. However only the copy in RAM is shown.


> 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