From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.220]) by sourceware.org (Postfix) with ESMTPS id 786B03858D20 for ; Thu, 10 Nov 2022 16:40:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 786B03858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gjlay.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=gjlay.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1668098449; s=strato-dkim-0002; d=gjlay.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=XVWRQO4wD2vvrAjEW5LteHtZHkPq8D8SeBhjNbwy0K4=; b=QtuUVqbQNXb5rQpQ2DSxd1hOONw0iQp+vco7NIB4jqx6+NgYcGn26ePtnG8VjTT7Co qWhiDwyvmtODFmMhpOB09P+wV/yNwjeK7NHa2tz2eP26a/IOl5+JwzF0pS5uJ6Bs8fMu jFVPeRDoFAcYo20gYX5DXI2Vitrvj9x4uMXsbJcxxKmEsKZD30fXlfTDx3sp9BFJbcsA tlr4XDIWIBKWZtXlSa8ZdQ8xqWOkmmN/LqMKQXJx7fFTjmuRGfu0iX2vNviDSLyCejP/ GbM0O1ysewkgl25xnEpGgw44DKKdVmLTCZuoDz9WY4oH5hIXaOXGbQoVX1KDhoBxqV06 L96w== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":LXoWVUeid/7A29J/hMvvT3koxZnKT7Qq0xotTetVnKkbjtK7qmy9Jvpc5Ezo" X-RZG-CLASS-ID: mo00 Received: from [192.168.2.102] by smtp.strato.de (RZmta 48.2.1 DYNA|AUTH) with ESMTPSA id aba1dcyAAGenRwU (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 10 Nov 2022 17:40:49 +0100 (CET) Message-ID: <3803548f-9437-4939-4f35-cbbfb61fdc1b@gjlay.de> Date: Thu, 10 Nov 2022 17:40:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v3] c++: parser - Support for target address spaces in C++ Content-Language: en-US To: Paul Iannetta Cc: Jason Merrill , gcc-patches@gcc.gnu.org References: <20221013160227.sdlv6yaw5gr4zcvd@ws2202.lin.mbt.kalray.eu> <20221013215643.o2bymrmffwbtuppu@ws2202.lin.mbt.kalray.eu> <4026cae9-e371-a2ee-2b36-7abc9224afa1@redhat.com> <20221018073731.wj2expjfmk5uhmp3@ws2202.lin.mbt.kalray.eu> <07d4c9ba-594a-d3f8-3df3-5ef5d18a6e97@redhat.com> <20221018170135.zpkmyebmpcvqx7ky@ws2202.lin.mbt.kalray.eu> <20221026071837.l3de5hkxujvqqztr@ws2202.lin.mbt.kalray.eu> <49b9d82e-3252-9e58-f064-b74f059d8b7d@gjlay.de> <20221110140838.7uupbxeretumhugk@ws2202.lin.mbt.kalray.eu> From: Georg-Johann Lay In-Reply-To: <20221110140838.7uupbxeretumhugk@ws2202.lin.mbt.kalray.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP 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: Am 10.11.22 um 15:08 schrieb Paul Iannetta: > On Thu, Nov 03, 2022 at 02:38:39PM +0100, Georg-Johann Lay wrote: >>> [PATCH v3] c++: parser - Support for target address spaces in C++ >> 2. Will it work with compound literals? >> ======================================= >> >> Currently, the following C code works for target avr: >> >> const __flash char *pHallo = (const __flash char[]) { "Hallo" }; >> >> This is a pointer in RAM (AS0) that holds the address of a string in flash >> (AS1) and is initialized with that address. Unfortunately, this does not >> work locally: >> >> const __flash char* get_hallo (void) >> { >> [static] const __flash char *p2 = (const __flash char[]) { "Hallo2" }; >> return p2; >> } >> >> foo.c: In function 'get_hallo': >> foo.c: error: compound literal qualified by address-space qualifier >> >> Is there any way to make this work now? Would be great! >> > > Currently, I implement the same restrictions as the C front-end, but I > think that this restriction could be lifted. Hi Paul, this would be great. FYI, due to AVR quirks, .rodata is located in RAM. Reason behind this is that in functions like char get_letter (const char *c) { return *c; } there is no means to determine whether get_letter was called with a const char* or a char*. Accessing flash vs. RAM would require different instructions, thus .rodata is part of RAM, so that RAM accesses will work in either case. The obvious problem is that this wastes RAM. One way out is to define address space in flash and to pass const __flash char*, where respective objects are located in flash (.progmem.data in case of avr). This is fine for objects which the application creates, but there are also artificial objects like vtables or cswtch tables. >> 3. Will TARGET_ADDR_SPACE_DIAGNOSE_USAGE still work? >> ==================================================== >> >> Currently there is target hook TARGET_ADDR_SPACE_DIAGNOSE_USAGE. >> I did not see it in your patches, so maybe I just missed it? See >> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gccint/Named-Address-Spaces.html#index-TARGET_005fADDR_005fSPACE_005fDIAGNOSE_005fUSAGE > > That was a point I overlooked in my previous patch. This will be in > my new revision where I also add implicit conversion between > address spaces and also expose TARGET_ADDR_SPACE_CONVERT. > >> 4. Will it be possible to put C++ virtual tables in ASs, and how? >> ================================================================= > > Currently, I do not allow the declaration of instances of classes in > an address space, mainly to not have to cope with the handling of the > this pointer. That is, > > __flash Myclass *t; > > does not work. Nevertheless, I admit that this is would be nice to > have. > >> One big complaint about avr-g++ is that there is no way to put vtables in >> flash (address-space 1) and to access them accordingly. How can this be >> achieved with C++ address spaces? > > Do you want only the vtables in the flash address space or do you want > to be able to have the whole class content. My question is about vtables, not the bits that represent some object. vtables are stored independently of objects, usually in .rodata + comdat. Notice that vtables are read-only and in static storage, even if objects are neither. The problem with vtables is that the user has no handle to specify where to locate them -- and even if, due to AVR quirks, the right instruction must be used. Thus just putting vtables in flash by means of some section attribute won't work, only address-spaces can do the trick. > 1. If you only want the vtables, I think that a target hook called > at vtable creation would do the trick. Yes, that would be enough, see https://gcc.gnu.org/PR43745 Johann > 2. If you want to be able to have pointer to classes in __flash, I > will need to further the support I have currently implemented to > support the pointer this qualified with an address space. > Retrospectively, I think this have to be implemented. > > Paul Would be great if this would work, but I think this can be really tricky, because it's already tricky for non-class objects. A user has to specify __flash explicitly, which is quite different to plain objects. For example, a const int can live in .rodata, but in cases like extern int func(); extern const int ival; const int ival = func(); ival would live in .bss and be initialized at runtime by a static constructor. Consequently, const __flash int ival = func(); is invalid code that has to be diagnosed [1], because in the avr case, __flash means non-volatile memory, which contradicts initialization at runtime. So only objects that are TREE_READONLY can go into AS __flash, TREE_CONST is not enough. How is this problem addressed? Does this require a new target hook to diagnose such cases, and does the compiler know at that stage that an object will be TREE_READONLY? [1] Notice that in C it's enough to check that __flash is always accompanied by const, but in C++ this is not more enough as shown in the example above. Johann p.s: I just checked clang v16, it doesn't complain and accepts nonsensical code like: extern int func(); extern const __flash int cval; const __flash int cval = func(); int get_cval() { return cval; } (clang puts cval into .bss and initializes at startup, but get_cval will read from flash due to __flash.)