From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.wavenetuk.net (smtp.wavenetuk.net [195.26.36.10]) by sourceware.org (Postfix) with ESMTP id 9BFC23857C4A for ; Sat, 15 Aug 2020 09:22:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9BFC23857C4A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=iain@sandoe.co.uk Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by smtp1.wavenetuk.net (Postfix) with ESMTPA id 81AA8120103E; Sat, 15 Aug 2020 10:22:39 +0100 (BST) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] introduce attribute exalias From: Iain Sandoe In-Reply-To: Date: Sat, 15 Aug 2020 10:22:30 +0100 Cc: Nathan Sidwell , Eric Botcazou , gcc-patches@gcc.gnu.org, joseph@codesourcery.com Content-Transfer-Encoding: 8bit Message-Id: <3BCD58FE-BB29-49EA-BBEF-1FF4ADCAB7CA@sandoe.co.uk> References: <13ed4563-33bb-f9b5-4b63-0cf0eebf6034@acm.org> To: Alexandre Oliva X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KHOP_HELO_FCRDNS, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 09:22:42 -0000 Hi Alexandre, I built the patch on x86_64-linux and darwin*** (fwiw). * It’s firmly agreed that there are times when referring to C++ mangled names is less than ideal. * IIUC, the objective is to have a short-hand way of annotating an export from C++ so that it’s (a) more human-readable and (b) independent of any platform variation in mangling of types - in the Ada import pragma? I see Nathan commented that there are no language-lawyering implications, which is good. However, there do seem to be both ABI and engineering implications: * if the target ABI does not support symbol aliases, then this facility cannot be used. Which either means that you cannot rely on this facility (and thus make things generically easier in the Ada implementation on GCC) or you will exclude the GCC targets without symbol aliases from Ada. The latter would make me sad as Darwin maintainer. * the symbol table will grow (maybe one doesn’t care if there are not many). * The process shifts the onus on representation to the exporter and thus there can now be 3 library vendors who all thought “MY_FOO_FUNC” was the best representation for an export - these will now clash in the “shorthand” namespace, although their C++ mangling might well not. * it’s not universally usable without “rebuilding the world” and having access to source for everything you might want to import (maybe not important, depends on whether there are users of Ada who depend on closed source libraries). * what happens for templates and overloads - presumably the Ada import has add the relevant (albeit abbreviated) decorations? * One can’t have an arbitrary re-name; it has to be supported by the target assembler (not that this is a new constraint, but it prevents the exported name from being an exact representation of the human-readable C++ interface in general). —— are there other possibilites to solve the underlying issue? C++ mangled names have some proven good properties: * they convey all the relevant information about the interface * they are standardized, and work between implementations from different ‘vendors’ or OSS compilers on the same platform. * they are not going to clash. The compiler already has a proven implementation of C++ mangling rules. what about annotating the import pragma in some way such that the platform mangling is applied by the compiler? thus, in my example below, so long as the interface is represented correctly by the string after “itanium:” it will mangle correctly for the target (even if that mangling would alter between targets for representation of some types). I suppose there’s a question of how many pragmas would be needed to annotate sufficiently to get the mangling right? pragma CPP_Constructor (New_Animal); pragma Import (CPP, New_Animal, itanium:”Animal()"); It seems one ideally wants the Ada moral equivalent of: extern “C++” { things we want to import. } which automagically does the right interface transforms and synthesizes the Ada interfaces required. Alexandre Oliva wrote: > On Aug 14, 2020, Nathan Sidwell wrote: > >> >> Perhaps alias is not the right name at all. > > I kind of like the explicit present of "alias" because, well, what we > get is an alias, to the point that, if asm aliases aren't available, it > won't work. And, if they are, you can use the so-assigned name as an > alias target, so it's a good thing if they're typographically related. > > One could even argue that this new attribute is more deserving of the > term alias than the existing one, and that the existing one should be > renamed to "aliased_to" or so. But I'm not seriously suggesting us to > rename a long-available attribute while assigning uses thereof a > different semantics, that would be preposterous. > > Since you don't seem to have liked 'aka' either, how about 'nickname', > or 'nicknamed'? A more convenient name to refer to an entity is exactly > what this is about, eh? .. assuming this facility was added ... .. my 0.02GBP contribution the the bikeshed painting fund would be…. it’s nice when an attribute reads in the source to tell you its purpose. so how about: “export_as” or “exported_as” (depending on whether one regards this as a command to the compiler, or an annotation). so : __attribute__ ((__export_as__ ("Ctor_For_Animal"))) // extra alias Animal() {Age_Count = 0;}; or: __attribute__ ((__exported_as__ ("Ctor_For_Animal"))) // extra alias Animal() {Age_Count = 0;}; thanks Iain *** right now Darwin fails silently (there doesn’t seem to be the usual error that the target doesn’t support that kind of alias).