From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 0EBB43858D35 for ; Fri, 3 Dec 2021 17:08:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0EBB43858D35 Received: by mail-pl1-x636.google.com with SMTP id m24so2523042pls.10 for ; Fri, 03 Dec 2021 09:08:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=AN+DLRX1ZGGB1l71oUvt8PMnSm+kt+b7ksaA4bAsYiA=; b=vobH0nluC/LfNwwhFKKLjhlktgiLYwNVJb5q4X0HHtblGgMpJDxpCTEH7nDZAIRdxx 30DQmvRk43Qaij99oWV8T9mQHeV1jWFgJg08hm8M9kqlX4OrRQFtE7+EyIoJNWiFLSxt S8T/XRGUh3cYRUDz7XaafeO9OPwK5eZyBYLg4OHcAOi0jf5lYiMu8FP6nAeDNQHoJyUo CeNH8bV7of1naUcluM/LoIbmQipa4fI4QFqWEjVfLRbta1OYI31aiDoYleNpP4w8ulF9 imRGD/Tg09w7Ree3qsEpz9gMGfobI/PvZP2fXee3IVMxAiNeuu1ibZuEy8d2lQAxTU9z PpTg== X-Gm-Message-State: AOAM530eXyr+GhYAAfIKls78SuNbZonnf7GKCLWC6PpiHlfbm+bjRft3 XAkK97HBM/4VyxCPUB+vLcY= X-Google-Smtp-Source: ABdhPJxIvq6zliY8LYIS2KNuiHIQINeFXRYE+aWzFyJk5M+h08LbVFG3BFeRADi8kejjsYq1ClHa4Q== X-Received: by 2002:a17:902:f54f:b0:143:b899:a9ce with SMTP id h15-20020a170902f54f00b00143b899a9cemr24054757plf.28.1638551335047; Fri, 03 Dec 2021 09:08:55 -0800 (PST) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id y23sm2798741pgf.86.2021.12.03.09.08.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Dec 2021 09:08:54 -0800 (PST) Message-ID: Date: Fri, 3 Dec 2021 10:08:53 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH 0/4] Add aarch64-darwin support for off-stack trampolines Content-Language: en-US To: Iain Sandoe Cc: Maxim Blinov , GCC Patches , Andrew Burgess References: <20211113094525.96299-1-maxim.blinov@embecosm.com> <20211113094525.96299-4-maxim.blinov@embecosm.com> <54bfdb93-7b94-8fc2-7b0b-ec17a3f11ee6@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 03 Dec 2021 17:08:57 -0000 On 12/3/2021 12:53 AM, Iain Sandoe wrote: > >> On 3 Dec 2021, at 03:12, Jeff Law wrote: >> >> >> >> On 11/22/2021 7:49 AM, Maxim Blinov wrote: >>> Hi all, apologies for forgetting to add the cover letter. >> No worries. I'd already assumed this was to support aarch64 trampolines on darwin by having them live elsewere as managed entities. >> >>> The motivation of this work is to provide (limited) support for GCC >>> nested function trampolines on targets that do not have an executable >>> stack. This code has been (roughly) tested by creating several >>> thousand nested functions (i.e. enough to force allocation of a new >>> page), making sure all the nested functions execute correctly, and >>> consequently returning back up and ensuring that the pages are freed >>> when there are no more active trampolines in them. >> Right. I'm looking at this wondering if we should do something similar for our new architecture. Avoiding executable stacks is a good thing :-) >>> One of the limitations of the implementation in its current state is >>> the inability to track longjmps. There has been some discussion about >>> instrumenting calls to setjmp/longjmp so that the state of trampolines >>> is correctly tracked and freed when necessary, however that hasn't >>> been worked on yet. >> So in the longjmp case, we just leak trampolines, right? I'd think that should be quite uncommon. It'd be nice to fix, but the benefits of non-executable stacks may ultimately be enough to overcome the limitation. >> >> The other question is why not do a scheme similar to what Ada does with function descriptors? Is that not feasible for some reason? I realize that hasn't been plumbed into the C/C++ compilers, but it may be another viable option. > The problem is that it breaks ABI ;) It was worth asking :-) > > [in a function ptr] we need an address bit to test to determine if we are handling a case which has the descriptor, or if we have a regular indirect call. > > Unfortunately, although aarch64 aligns functions to 4 bytes, the two lower bits are reserved by Arm and therefore we’d have to force function alignment to 8bytes and that’s an ABI break (that cannot reasonably be expected to happen) for aarch64-darwin (or any other arch that has a release in the wild, I’d imagine). > > (FWIW, This is what I’ve currently implemented on my development branch [not for C++, since that has no nested functions]. I implemented the change for Fortran and re-used Martin Uecker’s proposed C impl. - but I used one of the reserved address bits [as a work-around to get people going with the port]) Good to know.  I keep thinking I should revamp how our port handles nested functions.  Right now we're using the tried and true trampolines, but we've got low bits available, so we could go with function descriptor approach.  Or we could go with trampolines in mmap'd space approach.  I just don't want to use old fashioned trampolines :-) > > Here’s the thread discussing the situation when Martin proposed the change for C. > > https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg01532.html Yea, I vaguely remember the thread.  ABI stability is a pain :( jeff