From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NOR01-OL1-obe.outbound.protection.outlook.com (mail-ol1nor01on2056.outbound.protection.outlook.com [40.107.224.56]) by sourceware.org (Postfix) with ESMTPS id 8BE55385840E for ; Wed, 5 Jul 2023 17:39:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8BE55385840E Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=westcontrol.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=westcontrol.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=feUkmJaJH7PdIpVnYZZzPooQb1TXjyYf5cYlsmoZxA/kXD4BAuMgCi9PNTqcIqOPXIMntczhotUdhgm/inbP1F3/5TmAwOW4WFc7QafeUC1dlaNLyYGwddOtXREOuQXy8ihRJ+v8H4yp4Q7RKPTpN9Aid6qdTc8Bv4LqjbT33xcQf2iYTDtyAg/12Nyin6oCS2iU2l/CMFNhGAYTxvpFbIPHhZ4kOBSNWygRuZAnfjy1YV7d6eG+X2loicCAP/EeSeLwm2UoA7z18Yt6tyMJa9IUzrWgM5NJkiVncEIxZqAys7Lg7xraWvi+TA2d4pOpZaewUHv9eGbj6MxZiejU9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QDPE8PKUHS4oC+1OMcCiXNxBZQkxdFiojw2idAulG2w=; b=ASJl+woYxYtB1JNjcrs+hbWHcm2J1Rv9ZMKkeLYOREvunBbC4/QEswF+HBuI/QIe3LLPw53Ksr7x9RXKxGzJcc8k2etzKRpQwEXptjOORq1MGLiS4r/azlEbH7hl9vpSLEqf58UQSFZg7G8LZKZ3P0GdRMtPXkHg95nk9O1uwFYBc16VYwOaR5u4N01tOCd6JX2pis3TuhyEHxFMgkWZyYBuHcPTEr8454x8ilPEP6b9neTlZZluASAerbUTACRd/EiCqmxk1O+/09xcJGHCUU0Gpp6c+49x880U7RI/zejLRD1WUM2Ad4HDpkz8XSV4hmUcOD8efahBCOm5EIiv9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=westcontrol.com; dmarc=pass action=none header.from=westcontrol.com; dkim=pass header.d=westcontrol.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=westcontrol.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QDPE8PKUHS4oC+1OMcCiXNxBZQkxdFiojw2idAulG2w=; b=YATc8SPD7dUrNtIDKdmBg2y2FfIIraGL8FlbhT1P+7n2WC+sdfdqPBf0cUI4SoSpZz86GUGjnVBerVKdGkF9CnndGFwH8I0tHPvB21ivS1TF8f3+B4p9xrVjF3wgvO1uYCbc+6P43cx1f29eJMC+h5A5krckioJPvPpliJVDrWiOOLuk1oPa7E2rvVTe78Xiv2OSU1OpaxG5z+Q7X3T5w2qQSIlgpVj7euOOM1UgfLLXFFSgGhuq9UHehvBAcsrW0fOn0aygm6966lT7lZqo2ZgYOrjmSWsjd80VAJGui2V+ybgtYv40WHXxXEZLu2haspVGa88DT5OI2nVdv/aSRA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=westcontrol.com; Received: from SV0P279MB0233.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:b::13) by SV0P279MB0025.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6565.17; Wed, 5 Jul 2023 17:39:33 +0000 Received: from SV0P279MB0233.NORP279.PROD.OUTLOOK.COM ([fe80::b999:1d1d:3eb1:b8f1]) by SV0P279MB0233.NORP279.PROD.OUTLOOK.COM ([fe80::b999:1d1d:3eb1:b8f1%7]) with mapi id 15.20.6565.016; Wed, 5 Jul 2023 17:39:33 +0000 Message-ID: Date: Wed, 5 Jul 2023 19:39:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: wishlist: support for shorter pointers Content-Language: en-GB To: =?UTF-8?Q?Rafa=c5=82_Pietrak?= , 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> <4932e81f-18b5-81de-180b-181008b168f5@ztk-rp.eu> From: David Brown In-Reply-To: <4932e81f-18b5-81de-180b-181008b168f5@ztk-rp.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SV0P279CA0024.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:12::11) To SV0P279MB0233.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:b::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SV0P279MB0233:EE_|SV0P279MB0025:EE_ X-MS-Office365-Filtering-Correlation-Id: 98afc83d-e9fb-4a3c-0a1f-08db7d7ecb53 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LBnTtkjOODBZS6mALKTS5dgAjivPMjehqf2TOYlSSFNSxMjAULF7ISzaJygerfgaiIbiOMjd4inUlmYfDbDMnL6BwXoErkRCHxCiach+rungndliiZHQ70lFJ4W09DZZe/EAQu8Go1zXPX7/CohZJZ0GNBBVG4lQgjRKi32bW0j4h1HW0E9zON3tmvsgbZeuim8/JDVaajfxQPPMzAZxu9YC37YPFsXktLT2jPuivP6bdcwREHDtUM6OX3LYj3g7HjBTu0tC3gKKLW0Mdtd97CH8Sb+/ALkX5tZmRyEN9zha8kGLMF3BfI6OFWEZhE5C0FUItciXG/5vC/vGwIR/3GWoYz2AbY9N8NRDVff0yOs3ylijBGi1CVLalhwuRSV70OtIFcNRav3tulDgHBQ9o9TtvsFkeLW7dbXGBdTdEea1yi4mQYk7qe2tQhLZZrd2oyKJ/66nVsaFJuUBkn/8zwz7eSjNC8PWe9Ofse+G3Njy4cLOX79kgtq7KiJ/PLX7Y2npKIWc/Lz6ViLNOfxclOf004D04UybciX54t31wQzrhEvy1LmCf9EQTHFWEVVB7XbBcIxfiFynT0Q3t9eIrj1Ee8JGe6+hkvmYJaJQvIorW6Lq5YCJEHx1oa/UDmdSJ9/dURTVE3o9UPlQljgB4iY1APYaIhUVmUlMtZKHZNI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SV0P279MB0233.NORP279.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230028)(4636009)(396003)(366004)(136003)(376002)(39840400004)(346002)(451199021)(66946007)(38100700002)(4326008)(66476007)(66556008)(2616005)(186003)(86362001)(478600001)(31696002)(6486002)(6512007)(36756003)(26005)(53546011)(54906003)(6506007)(110136005)(8936002)(8676002)(5660300002)(31686004)(316002)(2906002)(66899021)(41300700001)(83380400001)(87944012)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TGRrZDVpa2VnSkdwc0F2YXhXYmJOSDI2MGR1OGlCTTBZcSsrOER2R3VNRUth?= =?utf-8?B?aERQaElDd3Q1cHE4Z3hiVUxVZytKbzZDTXRZTHZEQ0ZrdWVrNW1ZdkFYbHdq?= =?utf-8?B?ekpSdHJ1OVVKdnh1a3NZeE1OTzdPUUZWWVVjcFQ5bDJWYkdTN2NwMWFvOFJr?= =?utf-8?B?QXdtZTlTeDd0aWZDRVFpbnZyVVYwWmNEV0Y1dWY1WHpRNS9sQWdsdk9JaVVU?= =?utf-8?B?a2RrNUhTM2RnWHdhVURPWEY3cmpsWVBVRC9jOFJnd09nZGVGeVpBQVJEUUR0?= =?utf-8?B?aVNsdDQrZGxqa0pVOU9Od3hLRTVTU0VoR0tTZVNkVjE3LzdrMTBuMUZVQU11?= =?utf-8?B?M2YxdUJVZFJMN0gvNVNtVmxkNG1mTzQ3UDQyUm9YL01mUm5KVFJYR3hiMTA3?= =?utf-8?B?SmNGaGlidldCQStUSlhiUVpQZUtKL25zK0N1bzJCQUtrZmxVOFhxdnloK0p6?= =?utf-8?B?OWlTT1IrWURUQTZBa0RIQ0JvYVc2YnhkVUQzUkhPY1RmS2F3Vy9ROHFSRDJt?= =?utf-8?B?WE1KUTN3bmZXd090YmVsMXA5Nk1UQVAxcHNEOTB1aTh6ZWF3cXhiazBEeC83?= =?utf-8?B?MnNXbEVWMXMvWTJzZjA2N1R2K2pXRE1jazVic2o1RXg5RjVSZmkvUXpmc3Vz?= =?utf-8?B?ODMvMCtWTlJRNnVISnQzY0pqRHhDZm5UT0N5QUxEYkNENVNkU2pYMmJVMXo2?= =?utf-8?B?VG9xSGtaUVdTOEdFSFpzeEhLSG5pSUJUSXBmUVAwTngybS9qOHdHelFuVVAz?= =?utf-8?B?alpvRU9GK0QvYXFDcHBvU2FRSzg5Uys0Uk1QL0QyS3RUYzVxTnM1ZGJ0NEdm?= =?utf-8?B?cUl6OGQ0ZW9nbkdyRUkyRFppdnY1bGtzWmpIc0tzd2s5Y0dEcEtxNWZibmM5?= =?utf-8?B?eTc0aHBFaFNzRm15VjM3VHRwVWx0RFAwTWtUUTJ1VjBxam5vTE5XMmdDRGZF?= =?utf-8?B?elN2bjlRaTlBOVltUTB6T0ZlMjRmVXhjSkNiRzNpaEtjcUQyekNNdnA1bjFS?= =?utf-8?B?U2U3OHYrTG1ub0N1Yk5OKytzZEdxZGYzNmZXcVgyVnVpR25FT0hUUmNFWjBk?= =?utf-8?B?Y1FSL3UxakV5UlRPQ3UzdWJ6Umt3UEFkMjB6Sk5laUZTVEE1S2hDaVpWTjVr?= =?utf-8?B?YlBrNVlXWS9vVlJ2NGlHWmxsLzY0Ry81M0YyZmVFZm9PWFA1cWwyQUVNWXVQ?= =?utf-8?B?enorRGJJdkdSaHdGQjVnTXI2S0tjQUptY2lta2sxTFpDVFJGZ2hHaTZ1blh6?= =?utf-8?B?Lzl6RCtRS3NDRWRvWFByNXBnbElOT0xJNFM0N3V2MmpCd211U1kxVUFRcHFG?= =?utf-8?B?dFBSbTBJVTkydjdLZHo5eVFxTXdBK0tvSnJJVXpxaXllNGFvR1pVUDNvblhi?= =?utf-8?B?aFlwUHNGbEdLRFFaa2pVQ2pGelJKcVRjTVAvZ2xPdzNaYjdkTUhrOUJVQURZ?= =?utf-8?B?VHo2RGFOTWtIRjhzZGkyT1pEaVh4RGE0Rlo1SHdZeWtoWnBHcVhidjBUeDBJ?= =?utf-8?B?bE1ObFRzN1pjT1RpNndiZkNmcUppWVYwdU9sdGhZMkh5VHVycmZhR1VqRHAy?= =?utf-8?B?WFRqU1BsYW5kaERsUG1qclkxOTUvNEFUYmNGQndIaVNQSk9SMzQ5dzk1bkEx?= =?utf-8?B?THRHbGM4bUs5V1RuZWE5UnBsRXZZUGh1MmVZbTNGSHVoT0lOdDZRUGhxTUo5?= =?utf-8?B?c016cGtFaU5BZDFvem42TmIrOUo4bS9jVnBRcUgxSi9WYnhvMWlqaXBqZ296?= =?utf-8?B?TWdNZnFhdXBjVEtDbFhxWEU2S1pIOG9iZWtncW5tTTFzSTBGQTd6L25tWVAv?= =?utf-8?B?dVFISUs0bWk4ampQUUpQK1VEMXY4c25sMDU4MWFCOCtsaExlbE90MG8vbEZy?= =?utf-8?B?azgxeTJiSlY2K3BFTXl3VzhmeGxGY2dHbE5rVzkwWUwzWFBodUhFdmJLUFkw?= =?utf-8?B?RWJpRUxNRzdFSm1aSEJKUEZGUVB2amlyRnZQWkk2SnVkVCtXYVRYaW5BcG42?= =?utf-8?B?RlVnNThjaTQxaUhiS2I3bmQwVW1mN2lOR1NqWkY3Qmt4eVl2eVp0cGNnQks2?= =?utf-8?B?U3p3c1g1MmJ3WU5nMWozbFRyMnZNQXZRL1NPQTczU2RITG9mdnNHRHdRNGds?= =?utf-8?Q?P4EK6I5f+3H0/atUG1Pam8tP3?= X-OriginatorOrg: westcontrol.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98afc83d-e9fb-4a3c-0a1f-08db7d7ecb53 X-MS-Exchange-CrossTenant-AuthSource: SV0P279MB0233.NORP279.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2023 17:39:33.5506 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c75fbd3c-42ad-4db0-9cff-972faf83ae45 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HJOR1VUzUWGO0uNkTzYCh7+4J29EHTAHoGN92OL4Poxd3L/nQNRUuCYv4+ATgL9seWoJOt2XZ50sM4wApIvNsw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SV0P279MB0025 X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 05/07/2023 18:13, Rafał Pietrak via Gcc wrote: > 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. > No, it's about the access - not the allocation (or section). Access boils down to a "read" function and a "write" function (or possibly several, optimised for different sizes - C11 _Generic can make this neater, though C++ handles it better). > > [----------] >> 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? The compiler knows a lot more than just literal values at compile time - lots of things are "compile-time constants" without being literals that can be used in string literals. That includes the value of static "const" variables, and the results of calculations or "pure" function calls using compile-time constant data. You can do a great deal more of this in C++ than in C ("static const int N = 10; int arr[N];" is valid in C++, but not in C). Calculated section names might be useful for sections that later need to be sorted. To be fair, you can construct string literals by the preprocessor that would cover many cases. I can also add that generating linker symbols from compile-time constructed names could be useful, to use (abuse?) the linker to find issues across different source files. Imagine you have a microcontroller with multiple timers, and several sources that all need to use timers. A module that uses timer 1 could define a "using_timer_1" symbol for link time (but with no allocation to real memory). Another module might use timer 2 and define "using_timer_2". If a third module uses timer 1 again, then you'd get a link-time error with two conflicting definitions of "use_timer_1" and you'd know you have to change one of the modules. > >> 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? You can't have the same section name and multiple flags. But you sometimes want to have unusual flag combinations, such as executable ram sections for "run from ram" functions. > > 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? > Very often you have buffers in your programs, which you want to have statically allocated in ram (so they have a fixed address, perhaps specially aligned, and so you have a full overview of your memory usage in your map files), but you don't care about the contents at startup. Clearing these to 0 is just a waste of processor 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. These are ugly and hard to maintain in practice - the most common way to give fixed addresses is to use macros that cast the fixed address to pointers to volatile objects and structs. But sometimes it is nice to have sections at specific addresses, and it would be a significant gain for most people if these could be defined entirely in C (or C++), without editing linker files. Many embedded toolchains support such features - "int reg @ 0x1234;", or similar syntax. gcc has an "address" attribute for the AVR, but not as a common attribute. (It is always annoying when one target has an attribute that would be useful on other ports, but only exists on the one target.) > >> 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? They are, yes. But it would be useful to have non-debug user sections that act in a similar manner - it would not confuse debuggers, and be easier for user-written parsers to pull out of the elf or map files. > > 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, .... > }; > You also need control of the allocation (or lack thereof). This can be done using sections with flags and/or linker file setup, but again it would be good to have a standardised GCC extension for it. It is far easier for people to use a GCC attribute than to learn about the messy details of section flags and linker files. >> 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? You might like to have a code organisation where source files could define structures for, say, threads. Each of these would need an entry in a thread table holding priorities, run function pointer, etc. If this table were built up as a single section where each thread declaration contributed their part of it, then the global thread table would be built at link time rather than traditional run time setup. The advantages include a clear static measure of the number of the number of threads (see point 9), clear memory usage, and smaller initialisation code. (Obviously we are talking about statically defined threads here, not dynamically defined threads.) > > 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. > Fair enough.