From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sm.strop.com.pl (sm.strop.com.pl [83.17.179.219]) by sourceware.org (Postfix) with ESMTPS id 43144385B515 for ; Wed, 5 Jul 2023 16:14:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 43144385B515 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=ztk-rp.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ztk-rp.eu Received: from zorro.ztk-rp.eu ([::ffff:10.208.4.171]) (TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by sm.strop.com.pl with ESMTPS; Wed, 05 Jul 2023 18:13:16 +0200 id 000000001C809BC1.0000000064A5969C.000035F6 Received: from public-gprs569267.centertel.pl ([37.225.86.244]:13494 helo=[192.168.43.32]) by zorro.ztk-rp.eu with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qH57y-00Emro-GF; Wed, 05 Jul 2023 18:13:15 +0200 Message-ID: <4932e81f-18b5-81de-180b-181008b168f5@ztk-rp.eu> Date: Wed, 5 Jul 2023 18:13:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: David Brown , Martin Uecker , Ian Lance Taylor Cc: "Richard Earnshaw (lists)" , "gcc@gcc.gnu.org" References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> <940e9ae5-8649-5a28-e29f-06f0b2982892@ztk-rp.eu> <6c881d3fc76d112d52ec668d05b68394ae792f30.camel@gwdg.de> <1eeef918-80d0-12a3-e7e9-5a75b25fb769@ztk-rp.eu> <8825a11f-e462-8d97-3cdf-a5015250f3c1@westcontrol.com> <45292545-b4e1-a2c8-38d0-a7773f309ca5@ztk-rp.eu> <25afc1cb-3a62-135d-3206-2d9eb6216944@westcontrol.com> <701a38b8-9e90-36ce-9357-8b648f04a4d8@ztk-rp.eu> <540fa64b-0263-ba43-2c2a-2973ab376826@ztk-rp.eu> From: =?UTF-8?Q?Rafa=c5=82_Pietrak?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 37.225.86.244 X-SA-Exim-Mail-From: embedded@ztk-rp.eu X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,T_SPF_HELO_PERMERROR autolearn=ham autolearn_force=no version=3.4.6 Subject: Re: wishlist: support for shorter pointers X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000) X-SA-Exim-Scanned: Yes (on zorro.ztk-rp.eu) Received-SPF: unknown (IP address lookup failed.) SPF=FROM; sender=embedded@ztk-rp.eu; remoteip=::ffff:10.208.4.171; remotehost=; helo=zorro.ztk-rp.eu; receiver=sm.strop.com.pl; List-Id: Hi, W dniu 5.07.2023 o 16:45, David Brown pisze: > On 05/07/2023 15:29, Rafał Pietrak wrote: [---------------] >> OK. I don't see a problem here, but I admit that mixing semantics >> often lead to problems. >> > > I think it also allows better generalisation and flexibility if they are > separate.  You might want careful control over where something is > allocated, but the access would be using normal instructions. > Conversely, you might not be bothered about where the data is allocated, > but want control of access (maybe you want interrupts disabled around > accesses to make it atomic). that would require compiler to know the "semantics" of such section. I don't think you've listed it below, worth adding. If I understand you correctly, that means the code generated varies depending on target section selected. This is linker "talking" to compiler if I'm not mistaken. but OK. I see your point. [----------] > Let me try to list some things I think might be useful (there may be > some overlap).  I am not giving any particular order here. > > 1. Adding a prefix to section names rather than replacing them. OK. +1 > 2. Adding a suffix to section names. +1 > 3. Constructing section names at compile time, rather that just using a > string literal.  (String literals can be constructed using the > pre-processor, but that has its limitations.) I'm not sure what this means? At compile time, you only have literals, so what's missing? > 4. Pragmas to apply section names (or prefixes or suffixes) to a block > of definitions, changing the defaults. +1 > 5. Control of section flags (such as read-only, executable, etc.).  At > the moment, flags are added automatically depending on what you put into > the section (code, data, read-only data).  So if you want to override > these, such as to make a data section in ram that is executable (for > your JIT compiler :-) ), you need something like : > >     __attribute__((section("jit_buffer,\"ax\"\n@"))) I assume, that adding an attribute should split a particular section into "an old one" and "the new one with new attribute", right? One would need to have linker logic (and linker script definitions) altered, to follow that (other features so far wouldn't require any changes to linkers, I think). > to add the flags manually, then a newline, then a line comment character > (@ for ARM, but this varies according to target.) > > 6. Convenient support for non-initialised non-zeroed data sections in a > standardised way, without having to specify sections manually in the > source and linker setup. What gain and under which circumstances you get with this? I mean, why enforce keeping uninitialized memory fragment, while that is just a one shot action at load time? > 7. Convenient support for sections (or variables) placed at specific > addresses, in a standardised way. Hmm... Frankly, I'm quite comfortable with current features of linker script, and I do it like this: SECTIONS { sfr_devices 0x40000000 (NOLOAD): { . = ALIGN(1K); PROVIDE(TIM2 = .); . = 0x00400; PROVIDE(TIM3 = .); . = 0x00800; PROVIDE(TIM4 = .); } } The only problem is that so far I'm not aware of command line options to "supplement" default linker script with such fragment. Option "-T" replaces it, which is a nuisance. > 8. Convenient support for sections that are not allocated space by the > linker in the target memory, but where the contents are still included > in the elf file and map files, where they can be read by other tools. > (This could be used for external analysis tools.) Isn't it so, that current debugger sections are just that? Extrapolating your words: Do you think of sections that you would have full control on it's content at compilation, and it isn't sufficient to do it like this: char private[] __attribute__((section("something"))) = { 0xFF, 0x01, 0x02, .... }; > 9. Support for getting data from the linker to the code, such as section > sizes and start addresses, without having to manually add the symbols to > the linker file and declare extern symbols in the C or C++ code. +1 > 10. Support for structs (or C++ classes) where different parts of the > struct are in different sections.  This would mean the struct could only > be statically allocated (no stack allocation - just global or static), > and it would have no accessible address or size (you could have pointers > to fields, but not to the struct objects themselves).  This would let > you tie together objects made of multiple parts such as constant data in > flash and writeable data in ram. +1 > 11. Convenient support for building up tables where the contents are > scattered across different source files, without having to manually edit > the linker files. do you have an example where that is useful? 12. I'd supplement the list with a better control on code section names towards something like code namespaces. 13. and data sections "growing downwords" like stack does. This is for more flexible planning of memory layouts of micros (limited RAM). One class of sections you put into RAM sequencialy bottom to top, the other category from top to bottom. -R