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.