From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id 9562C3858C78 for ; Wed, 6 Sep 2023 14:03:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9562C3858C78 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=googlemail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=googlemail.com Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2bceb02fd2bso56094021fa.1 for ; Wed, 06 Sep 2023 07:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20221208; t=1694009031; x=1694613831; darn=gcc.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lR631eLGIQKiL+zXVxWlLbuusJoKwx/+fn4299q92nQ=; b=VIfz1X9GNuctW6BfNFnnYKnuP1tdmGHIP3Qo/KxTP6E5v09YIMIosfVoBgYNOolAYL OOxiplBat5mA1Mij63X5Yy1fOG46HoVjiCvrk9CVq5fg+cPRET8QYEmzDPVDD5EuhFgF T4DzKDoGoDjRb/VlrgyX/yxE0jx6QKWexBRHtRrwP24cvvNh6UubrYRgZahhVt1xbjzs 4y2jjF2rbWEkJjvVbltNyCt1adaV3dgFN4s4vskP29oSC+vQLv3v5aw+QYjmkayFETVM UBG7IpukzhZSWc+3UxR80s4/JcxQzQTzy1meB4emwMzljwjYTcvAcC7Mq2bUUkunf4MI pnlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694009031; x=1694613831; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lR631eLGIQKiL+zXVxWlLbuusJoKwx/+fn4299q92nQ=; b=iEW/FfR/47eVLbCn5y1Jk8HBUjLsvELDLw/L3cKd3QCvA1aDpb4k3DcsQ3lmmlKx3c dtTLrpdlnX2jWrRH9JGHpZe/HIXy/LYuZNtle8CpsCZS9pox09SED/LIZ95KMIDr3hvI v6xVFrnnP0KFdk6NzpDEleoSLX+yOVMTWTISQf3IZvzIhnL+e/yGtkeMs2vh20ZWXq6q 5nIQ09nb81tVk8+KIrUYUobHqbdM9nQNRdd1yjWosREMb6n/q6f2iMubF00Ng71s4DE8 Ryi0qSgCExfqg7e1fI85xO46J4sYS7chg1VH1nGMMGcFkMoXcC63gzQvjDur4DYqRYLJ c+oQ== X-Gm-Message-State: AOJu0Yw++s7qXtPwQrCxdboeExCJ9qf68xyl5L5+A0gVcjE+sbMFossm 6dvh5J2kCNoRHQHI4mr0VO4= X-Google-Smtp-Source: AGHT+IENm9JEvydJZtdISj1npuufVkZCc32s8ijqh9UhIfck0yKifdhPqUmznLqgNLSTT4AaXmi4kQ== X-Received: by 2002:a2e:b1c8:0:b0:2bd:a5e:2255 with SMTP id e8-20020a2eb1c8000000b002bd0a5e2255mr2407575lja.28.1694009030604; Wed, 06 Sep 2023 07:03:50 -0700 (PDT) Received: from smtpclient.apple (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id g26-20020a7bc4da000000b003fee8502999sm22997984wmk.18.2023.09.06.07.03.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Sep 2023 07:03:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: Question on aarch64 prologue code. From: Iain Sandoe In-Reply-To: Date: Wed, 6 Sep 2023 15:03:49 +0100 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <66FBEE1F-A485-4D2D-AD49-8A0F2D14723B@googlemail.com> References: <9C47ECA6-D1CF-4020-8BC5-B4C0D2C9C671@googlemail.com> To: Richard Sandiford X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Richard, > On 6 Sep 2023, at 13:43, Richard Sandiford via Gcc = wrote: >=20 > Iain Sandoe writes: >> On the Darwin aarch64 port, we have a number of cleanup test fails = (pretty much corresponding to the [still open] = https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D39244). However, let=E2=80= =99s assume that bug could be a red herring.. >>=20 >> the underlying reason is missing CFI for the set of the FP which = [with Darwin=E2=80=99s LLVM libunwind impl.] breaks the unwind through = the function that triggers a signal. >=20 > Just curious, do you have more details about why that is? If the = unwinder > is sophisticated enough to process CFI, it seems odd that it requires = the > CFA to be defined in terms of the frame pointer. Let me see if I can answer that below. >> <=E2=80=94=E2=80=94 >>=20 >> I have currently worked around this by defining a = TARGET_FRAME_POINTER_REQUIRED which returns true unless the function is = a leaf (if that=E2=80=99s the correct solution, then all is fine). >=20 > I suppose it depends on why the frame-pointer-based CFA is important > for Darwin. If it's due to a more general requirement for a frame > pointer to be used, then yeah, that's probably the right fix. The Darwin ABI mandates a frame pointer (although it is omitted by = clang for leaf functions). > If it's > more a quirk of the unwinder. then we could probably expose whatever > that quirk is as a new status bit. Target-independent code in > dwarf2cfi.cc would then need to be aware as well. (I suspect) it is the interaction between the mandatory FP and the fact = that GCC lays out the stack differently from the other Darwin toolchains = at present [port Issue #19]. For the system toolchain, 30 and 29 are always placed first, right below = the SP (other callee saves are made below that in a specified order and = always in pairs - presumably, with an uneccessary spill half the time) - = Actually, I had a look at the weekend, but cannot find specific = documentation on this particular aspect of the ABI (but, of course, the = de facto ABI is what the system toolchain does, regardless of = presence/absence of any such doc). However (speculation) that means that the FP is not saved where the = system tools expect it, maybe that is confusing the unwinder absent the = fp cfa. Of course, it could also just be an unwinder bug that is never = triggered by clang=E2=80=99s codegen. GCC=E2=80=99s different layout currently defeats compact unwinding on = all but leaf frames, so one day I want to fix it ... .. however making this change is quite heavy lifting and I think there = are higher priorities for the port (so, as long as we have working = unwind and no observable fallout, I am deferring that change). Note that Darwin=E2=80=99s ABI also has a red zone (but we have not yet = made any use of this, since there is no existing aarch64 impl. and = I=E2=80=99ve not had time to get to it). However, AFAICS that is an = optimisation - we can still be correct without it. >> =E2=80=94=E2=80=94=E2=80=94 >>=20 >> However, it does seem odd that the existing code sets up the FP, but = never produces any CFA for it. >>=20 >> So is this a possible bug, or just that I misunderstand the relevant = set of circumstances? >=20 > emit_frame_chain fulfills an ABI requirement that every non-leaf = function > set up a frame-chain record. When emit_frame_chain && = !frame_pointer_needed, > we set up the FP for ABI purposes only. GCC can still access = everything > relative to the stack pointer, and it can still describe the CFI based > purely on the stack pointer. Thanks that makes sense - I guess libunwind is never used with aarch64 linux, even in a = clang/llvm toolchain. >=20 > glibc-based systems only need the CFA to be based on the frame pointer > if the stack pointer moves during the body of the function (usually = due > to alloca or VLAs). I=E2=80=99d have to poke more at the unwinder code and do some more = debugging - it seems reasonable that it could work for any unwinder = that=E2=80=99s based on DWARF (although, if we have completely missing = unwind info, then the different stack layout would surely defeat any = fallback proceedure). thanks Iain >=20 > Thanks, > Richard