From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id B48333858C78 for ; Wed, 6 Sep 2023 10:04:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B48333858C78 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-wr1-x42d.google.com with SMTP id ffacd0b85a97d-31c8321c48fso477877f8f.1 for ; Wed, 06 Sep 2023 03:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20221208; t=1693994642; x=1694599442; darn=gcc.gnu.org; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=QGjEYoBnPR5PZ8MufTI8dAYqIg7AbBsufkTtr6vRzvs=; b=pBFwhj6se5CvJnq92i1PVLll0qeg90RFSOJG3uRH6F/P7zDEmMowgfzWqBrqnIsDNt 7CpFGT4RpM2NPvUtxua3Qpqg625gNtag6LT0g2Ulk8pOXcYAneF/nju2SRZiIX0ZajWX 9Mf2Hscrrx+MBAsuT77h7hxAodAzlqSPgc3HrHbU/2HKbZCFeDjpa0GQby+WiKJ5VTrA XZEU4Z30HMOkarj06JfMV/0RTa+j3sQaxSVtHRkwfOFfn+4aV00N7MYC+23nm5Tc2QjT AClZLfG967Z2Teur4OsjqOZkDLeczXmOpALFChe2PXC020zZ7rypFkjSABXUVWgvZWkm Chtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693994642; x=1694599442; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QGjEYoBnPR5PZ8MufTI8dAYqIg7AbBsufkTtr6vRzvs=; b=Qr8Z8a+cfUOhIKdgqlwemzEDUwEufvu7nWVPUK/BtAvJP+yenDCKxDOPrIglnh/7FU 7RSAQ2cR5vICSFGYWdaRTe89ZsD+2T7J7Zo086BNKgNiCOkUoSdPk+3L0QOb6LVIzqgy +i/f68niUI+BJDC48v+TgIXlHZqyuONR/c2ZTv9kaX9wumFNWmbVGcvrG2Hv5aMG4dn3 RpWX7xhGVYbmXPU/pRci30ZnUS7yR9fvS00L/Kal2faU+CJoDcxpzzG7LrYC+BiKuJ72 /8gB0Z+aQfrlqMCa8qGLhop0gcyhWc9jova5uWeIFkS25JXbmRRCbZkJmEeSnUl8GGwg oCuA== X-Gm-Message-State: AOJu0Ywfo/PJNW9L2MSiehMrxhCzET8mqqBEGXPMD/6FuTEXmh1Rwns9 M780uenDfw2L8C2rkq5i2cx46LrOZ2Q= X-Google-Smtp-Source: AGHT+IGpnNkUym4ruID41vdqSuHDRjG5GlaM92pU3m8pAbfAJUUQhXxdiZEhf1G6NIWBh0YNlYpPGg== X-Received: by 2002:a5d:6b04:0:b0:317:52ba:81f2 with SMTP id v4-20020a5d6b04000000b0031752ba81f2mr2065926wrw.16.1693994642197; Wed, 06 Sep 2023 03:04:02 -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 k8-20020a5d4288000000b003176aa612b1sm19972508wrq.38.2023.09.06.03.04.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Sep 2023 03:04:01 -0700 (PDT) From: Iain Sandoe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Question on aarch64 prologue code. Message-Id: <9C47ECA6-D1CF-4020-8BC5-B4C0D2C9C671@googlemail.com> Date: Wed, 6 Sep 2023 11:04:00 +0100 Cc: Richard Sandiford To: GCC Development 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,WEIRD_PORT 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 Folks, 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.. 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. =E2=80=94=E2=80=94=E2=80=94 taking one of the functions in cleanup-8.C (say fn1) which contains = calls. what I am seeing is something like: __ZL3fn1v: LFB28: ; BLOCK 2, count:1073741824 (estimated locally) seq:0 ; PRED: ENTRY [always] count:1073741824 (estimated locally, freq = 1.0000) (FALLTHRU) stp x29, x30, [sp, -32]! // LCFI; or .cfi_xxx is present mov x29, sp // *** NO LCFI (or .cfi_cfa_xxxx when that is enabled) str x19, [sp, 16] // LCFI / .cfi_xxxx is present. adrp x19, __ZL3fn4i@PAGE add x19, x19, __ZL3fn4i@PAGEOFF;momd mov x1, x19 mov w0, 11 bl _signal =E2=80=94=E2=80=94=E2=80=94 The reason seems to be that, in expand_prolog, emit_frame_chain is true = (as we would expect, given that this function makes calls). However = =E2=80=98frame_pointer_needed' is false, so that the call to = aarch64_add_offset() [line aarch64.cc:10405] does not add CFA = adjustments to the load of x29. =E2=80=94=E2=80=94=E2=80=94 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). =E2=80=94=E2=80=94=E2=80=94 However, it does seem odd that the existing code sets up the FP, but = never produces any CFA for it. So is this a possible bug, or just that I misunderstand the relevant set = of circumstances? thanks. Iain