From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46823 invoked by alias); 21 Dec 2018 21:13:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 46811 invoked by uid 89); 21 Dec 2018 21:13:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=highlights, apis, H*f:sk:8180496, H*f:sk:1545070 X-HELO: arjuna.pair.com Received: from arjuna.pair.com (HELO arjuna.pair.com) (209.68.5.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Dec 2018 21:13:05 +0000 Received: by arjuna.pair.com (Postfix, from userid 3006) id B52928A570; Fri, 21 Dec 2018 16:13:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by arjuna.pair.com (Postfix) with ESMTP id B41E88A56F; Fri, 21 Dec 2018 16:13:03 -0500 (EST) Date: Fri, 21 Dec 2018 21:41:00 -0000 From: Hans-Peter Nilsson To: "Uecker, Martin" cc: "law@redhat.com" , "jakub@redhat.com" , "nd@arm.com" , "paulkoning@comcast.net" , "Szabolcs.Nagy@arm.com" , "msebor@gmail.com" , "gcc-patches@gcc.gnu.org" , "Wilco.Dijkstra@arm.com" , "ebotcazou@adacore.com" , "joseph@codesourcery.com" Subject: Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C In-Reply-To: <1545150827.16327.1.camel@med.uni-goettingen.de> Message-ID: References: <56b1e591-4d32-672f-6a30-11a9a0b167b7@gmail.com> <1544967934.14155.1.camel@med.uni-goettingen.de> <1545000327.30232.11.camel@med.uni-goettingen.de> <05b12e7e-b6dd-fa8d-94cb-35ec9c512950@arm.com> <1545070952.3328.5.camel@med.uni-goettingen.de> <5896AE4C-D296-4FAF-A809-7BACA532BBF5@comcast.net> <20181218153209.GP23305@tucnak> <81804969-da3b-80b8-98d2-beb31cd19541@redhat.com> <20181218162440.GQ23305@tucnak> <1545150562.7930.4.camel@med.uni-goettingen.de> <1545150827.16327.1.camel@med.uni-goettingen.de> User-Agent: Alpine 2.20.16 (BSF 172 2016-09-29) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1823847789-618954476-1545426783=:97109" X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01613.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1823847789-618954476-1545426783=:97109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-length: 2567 On Tue, 18 Dec 2018, Uecker, Martin wrote: > Am Dienstag, den 18.12.2018, 17:29 +0100 schrieb Martin Uecker: > > Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek: > > > On Tue, Dec 18, 2018 at 09:03:41AM -0700, Jeff Law wrote: > > > > Right.  This is the classic example and highlights the ABI concerns.  If > > > > we use the low bit to distinguish between a normal function pointer and > > > > a pointer to a descriptor and qsort doesn't know about it, then we lose. > > > > > > > > One way around this is to make *all* function pointers be some kind of > > > > descriptor and route all indirect calls through a resolver.  THen you > > > > > > Either way, you are creating a new ABI for calling functions through > > > function pointers.  Because of how rarely GNU C nested functions are used > > > these days, if we want to do anything I'd think it might be better to use > > > trampolines, just don't place them on the stack, say have a mmaped page of > > > trampolines perhaps with some pointer encryption to where they jump to, so > > > it isn't a way to circumvent non-executable stack, and have some register > > > and unregister function you'd call to get or release the trampoline. > > > If more trampolines are needed than currently available, the library could > > > just mmap another such page.  A problem is how it should interact with > > > longjmp or similar APIs, because then we could leak some trampolines (no > > > "destructor" for the trampoline would be called.  The leaking could be > > > handled e.g. through remembering the thread and frame pointer for which it > > > has been allocated and if you ask for a new trampoline with a frame pointer > > > above the already allocated one, release those entries or reuse them, > > > instead of allocating a new one.  And somehow deal with thread exit. > > > > Yes, something like this. If the trampolines are pre-allocated, this could > > even avoid the need to clear the cache on archs where this is needed. > > And if we can make the trampolines be all the same (and it somehow derived > from the IP where it has to look for the static chain), we could map the > same page of pre-allocated trampolines and not use memory on platforms > with virtual memory. All fine with new ideas, but consider the case where the nested functions are nested. All mentioned ideas seem to fail for the case where a caller (generating a trampoline to be called later) is re-entered, i.e. need to generate another trampoline. The same location can't be re-used. You need a sort of stack. brgds, H-P --1823847789-618954476-1545426783=:97109--