From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1373B3830B02 for ; Mon, 14 Nov 2022 17:56:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1373B3830B02 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668448559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Utnm1gZ4hpkklk01rlzidwZ6c0YCSXfuZkGVNy6qGtY=; b=EHEVo/FdUsf9Mhe4SMMMJkeM0WN9ydzuOOJTmk4C902KbKFaNctOkXLKuCG/8Z3P1dF6+i Z51kRyFz7ZMbwHd1QOdXgVymPWf8wwXAA5NAYvGuhS17XMKFkHVPdFYeqkAcfGiQSTmJvY AjiNALQUnES3T3orD39yFMaqpT0licE= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-156-e5Q0AvBhNOm7iHYjF8wg7A-1; Mon, 14 Nov 2022 12:55:58 -0500 X-MC-Unique: e5Q0AvBhNOm7iHYjF8wg7A-1 Received: by mail-qt1-f198.google.com with SMTP id fb5-20020a05622a480500b003a525d52abcso8515683qtb.10 for ; Mon, 14 Nov 2022 09:55:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Utnm1gZ4hpkklk01rlzidwZ6c0YCSXfuZkGVNy6qGtY=; b=cfiR/poi3ty9JKHELNBXNRiy88PQE9Ti7WCkbCrK/6teDtHZuuoCTPgZ1moSLU7sbz G/lCzgOHAgJtBpCi+S29H5RD60KdteEzfRFR7Fk59eIiRINMef+5ov7Ch6TcpmAF8IDg vKBoJU1cTdwAKRLdm+mNyNpftR8lzQ79lxDO7WblL8Re89/m8i3+CRcvEBRRo+AlUTMC tr2NgJ3MQC4p1F1juqtUzym/CwnukvzqdWyu8QjgEp4zf0tcDU0iVP1g1bP8AFhEESJt vS/F1I5xw5KuWA+ot3cSV9icLlHS8utB+ipBMf6RFfRscpJ2qTscD+OzM8K5Z+GDos3V pzgQ== X-Gm-Message-State: ANoB5pmT+edSNaGq9e8xkqSjkG3rAY1jw6qdfRBSwmI9PxNJ0hmyFrT9 drRGDYc2tSNBS0hp6xXE6n9PLCGv5KOW+q34KzrV2wTqSx9+5Ie+ozLLbvjaimT5V3ZQCqzBv5N +VAlOsOwLdum6zNxgpA== X-Received: by 2002:ae9:e314:0:b0:6f4:841d:abec with SMTP id v20-20020ae9e314000000b006f4841dabecmr12200308qkf.62.1668448557957; Mon, 14 Nov 2022 09:55:57 -0800 (PST) X-Google-Smtp-Source: AA0mqf7jpx0LIamjXkyIHUrO1WXLipPvaCBzUah7vnGmE1Rr8qdqqs2bUJXyDBpHtZzDF4jiMk1T5A== X-Received: by 2002:ae9:e314:0:b0:6f4:841d:abec with SMTP id v20-20020ae9e314000000b006f4841dabecmr12200276qkf.62.1668448557522; Mon, 14 Nov 2022 09:55:57 -0800 (PST) Received: from [192.168.1.101] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id c8-20020a05620a268800b006eecc4a0de9sm6859818qkp.62.2022.11.14.09.55.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 09:55:56 -0800 (PST) Message-ID: <2184e167-795f-126b-b535-fe3130441e08@redhat.com> Date: Mon, 14 Nov 2022 12:55:55 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v3] c++: parser - Support for target address spaces in C++ To: Georg-Johann Lay , Paul Iannetta Cc: 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> <3803548f-9437-4939-4f35-cbbfb61fdc1b@gjlay.de> From: Jason Merrill In-Reply-To: <3803548f-9437-4939-4f35-cbbfb61fdc1b@gjlay.de> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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 11/10/22 06:40, Georg-Johann Lay wrote: > > > 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! I don't object to allowing this, but what's the advantage of this pattern over static __flash const char p2[] = "Hallo2"; ? >> 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 As you say there, this would be an ABI change, so there would need to be a transition strategy. I don't know to what extent AVR users try to use older compiled code vs. always rebuilding everything. > 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. Indeed, especially if objects of the same type can live either in flash or RAM: you'd need 2 or more of each method for the different accesses. Perhaps via cloning. Simpler might be to declare that objects of a particular class can only live in flash. > 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? That does sound like a job for a new target hook, if there isn't a suitable one already. > [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.) >