From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from spam02.hesby.net (spam01.hesby.net [81.29.32.152]) by sourceware.org (Postfix) with ESMTP id 9BF753858D1E for ; Sat, 26 Feb 2022 18:56:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9BF753858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hesbynett.no Received: from [192.168.4.227] (247.92-221-34.customer.lyse.net [92.221.34.247]) by spam02.hesby.net (Halon) with ESMTPSA id debd62e0-9735-11ec-920b-506b8dfa0e58; Sat, 26 Feb 2022 19:56:56 +0100 (CET) Subject: Re: AW: Constant at fixed address To: stefan@franke.ms, gcc-help@gcc.gnu.org References: <723b5ea5-7cbb-a36e-0734-9cae443eda70@gmail.com> <026001d82a74$0f3082c0$2d918840$@franke.ms> From: David Brown Message-ID: Date: Sat, 26 Feb 2022 19:56:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <026001d82a74$0f3082c0$2d918840$@franke.ms> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3033.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 18:57:03 -0000 On 25/02/2022 19:18, stefan@franke.ms wrote: > > >> -----Ursprüngliche Nachricht----- >> Von: Gcc-help Im >> Auftrag von David Brown >> Gesendet: Freitag, 25. Februar 2022 18:57 >> An: Martin Sebor ; Henrique Coser >> ; gcc-help@gcc.gnu.org >> Betreff: Re: Constant at fixed address >> >> On 25/02/2022 17:45, Martin Sebor via Gcc-help wrote: >>> On 2/25/22 09:01, Henrique Coser wrote: >>>> Hello, >>>> >>>> I need a help. I'm trying to solve a problem for weeks. >>>> I have a embeded software that is a boot loader. It puts the boot >>>> load version at a specific address. >>>> My memmory starts at 0x400000 with 0x1400 size. My constant version >>>> string value must be placed @0x401000 with 8bytes length. >>>> If I place this const value into a section like this: >>>> >>>> const unsigned char Version[8] __attribute__ ((section >>>> (".bootversion"))) = "V1.0.1a"; >>>> >>>> I got this error: >>>> >>>> section .bootversion LMA [00401000,00401007] overlaps section .text >>>> LMA [00400000,00401013]collect2.exe(0,0): error: ld returned 1 exit >>>> status >>>> >>>> I have already tried to split flash memmory using linker script but >>>> it does not worked. >>>> I wish to find something like "automatic" split. >>>> >>>> For example, this code was compiled using ARM Keil. With ARM Keil I >>>> have the attribute that makes all the magic : >>>> const unsigned char Version[8] __attribute__((at(0x0401000))) = >>>> "V1.0.1a"; >>>> >>>> I dont know if is possible to have something as pratical as ARM Keil >>>> attribute in GCC. >>> >>> GCC for the AVR target supports a couple of attributes that can be >>> used to pin a variable declaration to a fixed address: address and io. >>> It doesn't look to me like they're put in their own sections like in >>> the ARM Keil compiler (but the section attribute can be used for >>> that). >>> >>> Beside your use case, exposing at least the address attribute in all >>> targets would make would also solve a long-standing problem with GCC >>> issuing warnings for accesses to hardwired addresses). >>> >>> I suggest opening an enhancement request in Bugzilla. >>> >>> Martin >>> >>> >> >> I second that request - it would definitely be convenient to be able to put a >> variable or section at a specific address without having to modify a linker >> script. This is a feature that most embedded toolchains (Keil, IAR, etc.) >> support. >> >> Note that the attributes for the AVR here don't do what is needed, as far as I >> can see - it looks like they declare the variable at the given address, but that >> does not mean that there will be an absolute section allocated in the link. In >> other words, using the AVR "address" >> attribute to put "Version" at address 0x0401000 will not actually put the >> initialised data there, nor will it prevent the address being used by anything >> else that is linked to that memory area. >> >> The example for the "address" attribute is : >> >> volatile int porta __attribute__((address (0x600))); >> >> The effect of this is very similar to the more common and portable version >> used for other targets: >> >> #define porta *((volatile int *) 0x600) >> >> Henrique needs more than that here. >> >> AFAIK, Henrique, the only way to achieve your needs are a modified linker >> script. It's not hard to do that, but of course it looks hard the first time you >> do it! Post a copy of your current linker script and I can try to give you ideas >> for modification. >> >> > > Isn't this already possible by using a section: > > volatile int porta __attribute__((__section("section_600"))); > > and using an appropriate linker script? > > SECTIONS > { > .section_600 0x600: { > *(.section_600) > ... > > > Stefan > Exactly, yes. The point is that with gcc (and standard binutils) you need to modify (or suppliment) the linker script to do this. The OP is used to a toolchain where you can specify this using an attribute in the compiler alone, which is neater.