From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 3B7D038708D1 for ; Thu, 14 Jan 2021 19:00:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3B7D038708D1 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AAB62ED1; Thu, 14 Jan 2021 11:00:44 -0800 (PST) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2E1B53F719; Thu, 14 Jan 2021 11:00:44 -0800 (PST) Subject: Re: Patches for targeting AArch64 Darwin with clang To: Siguza , newlib@sourceware.org References: <983159DB-FF02-4264-A7F2-AC963A4C68F7@siguza.net> From: Richard Earnshaw Message-ID: <861e2287-38f3-f96f-5213-c51a6d252516@foss.arm.com> Date: Thu, 14 Jan 2021 19:00:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <983159DB-FF02-4264-A7F2-AC963A4C68F7@siguza.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3498.7 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 19:00:46 -0000 On 11/01/2021 23:15, Siguza via Newlib wrote: > Hi > > We at the checkra1n team are using Newlib as the standard library of a pre-boot bare metal execution environment on jailbroken iPhones (i.e. aarch64). > As our target is using the Darwin ABI and we're building with clang, we had to apply some patches. We'd like to upstream those. > > The first two patches should be uncontroversial. They merely consist of: > 1. an additional header include (which causes a warning for Linux/ELF targets, but which seems to be fatal when targeting Darwin). > 2. a change that makes all AArch64 "p2align" directives default to 2 rather than 0 (which I'm assuming is done implicitly anyway for non-Darwin targets?). > > The third patch changes SIMD/Neon register arguments in instructions that move between general-purpose and vector registers. > This is requires when building with clang, even for non-Darwin targets. As far as I can tell, the "d" in "reg.d[0]" does not appear in the ARMv8 Reference Manual and is a gcc-specific thing. I'm assuming it has no actual meaning and gcc just silently ignores it, but I didn't find any actual documentation on that. > > The fourth patch makes all the AArch64 assembly files compatible with the Darwin ABI. In particular: > - The .type and .size directives are illegal for Darwin targets, so they are wrapped in "#ifndef __APPLE__" blocks. > - Macro invocations must separate arguments by commas, otherwise they are concatenated and treated as one argument. This should work on all targets and not require any ifdefs. > - Darwin prefixes C symbols with an underscore, so the assembly for e.g. memcpy has to use _memcpy as label. I figured the least invasive patch for this was to just #define these symbols when targeting Darwin. > - In one case there was a "b.hs memcpy". Darwin seems to not allow jumping to external labels in conditional branches, so I replaced that with a conditional jump to a local label, followed by an unconditional jump to the external one. > > Please find the patches attached below. > > - Siguza > Please separate this out into individual patches for each issue. It's difficult to review it when it's all mixed together and for longer term maintenance we'll probably want to commit the changes separately as well. The best way to handle label prefixes for public functions is to define something similar to the way the Arm port does this. #define CONCAT(a, b) CONCAT2(a, b) #define CONCAT2(a, b) a ## b #ifdef __USER_LABEL_PREFIX__ #define FUNCTION( name ) CONCAT (__USER_LABEL_PREFIX__, name) #else #error __USER_LABEL_PREFIX is not defined #endif I'd expect your C compiler to define __USER_LABEL_PREFIX__ appropriately for your platform (GCC does this anyway). Now you can just wrap all public names with FUNCTION() and the preprocessor will handle this automatically. This is significantly preferable to littering the code with platform-specific ifdefs. R. > > > From 461d0a53041b94d23c3dd76b785b60b675ebdaa5 Mon Sep 17 00:00:00 2001 > From: Siguza > Date: Mon, 11 Jan 2021 22:47:57 +0100 > Subject: [PATCH 1/4] Fix include of _memalign_r in aligned_alloc.c > > --- > newlib/libc/stdlib/aligned_alloc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/newlib/libc/stdlib/aligned_alloc.c b/newlib/libc/stdlib/aligned_alloc.c > index feb22c24b..ad8887bd0 100644 > --- a/newlib/libc/stdlib/aligned_alloc.c > +++ b/newlib/libc/stdlib/aligned_alloc.c > @@ -26,6 +26,7 @@ > NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS > SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ > > +#include > #include > #include > >