Deutsch   English   Français   Italiano  
<vlpf2d$3hq9c$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: pozz <pozzugno@gmail.com>
Newsgroups: comp.arch.embedded
Subject: Re: Questions on arm-gcc linking: .ARM.exidx and .relocate sections
Date: Thu, 9 Jan 2025 22:28:00 +0100
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <vlpf2d$3hq9c$1@dont-email.me>
References: <vlo2f1$38sto$1@dont-email.me> <vlogbq$3bs33$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 09 Jan 2025 22:28:46 +0100 (CET)
Injection-Info: dont-email.me; posting-host="dc853eb18f352c9993c11267f3612a24";
	logging-data="3729708"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/vqv/bDWsj6xab3zg71MFyz8/cI2vVbWk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:HfNw6b1OFWIgc8tMNWmlOVz4iC0=
Content-Language: it
In-Reply-To: <vlogbq$3bs33$2@dont-email.me>
Bytes: 5777

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.