Message ID | 20250421124729.36364-1-anatoly.parshintsev@syntacore.com |
---|---|
State | New |
Headers | show
Return-Path: <opensbi-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=mpi7iYJ1; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=syntacore.com header.i=@syntacore.com header.a=rsa-sha256 header.s=m header.b=GDzSJuW1; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org; envelope-from=opensbi-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4Zh4s85TmBz1yNB for <incoming@patchwork.ozlabs.org>; Mon, 21 Apr 2025 22:47:38 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:CC :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=5bfDne47kvS+m357Z1zgPHbn/L1lmBHNUBvkZbSNNKc=; b=mpi7iYJ1NbHJv6 VqzfL21gSvzhiTsG2BnMl5EJyJ3t+gcFBFw8DAq1uZGTSVvoHGT9NMZd3HleLi8DpiLi4H+jZN4lr WO7XezBO+5b6/N6SOWo/Gca/baUGKufa5wN1i6C/mE+2+6/oXtoMJfKB/rYUwjm5N2YZIyybuYwYg gewELyDJOvmjnL3HRiiQcgh8JDoq40+EKJ0fPNotoGj0e64fuKWjvvO7nkfUYhrNBIG10bYraK/EF hhSpCcaGDtFHSa59LvEDEGJpx7i+ALvcIk+DE2kwvFbLre5ytJcVnWBt4wXAbBXrrE0qtmaPL3SML 7crqFyu/FIn2PTS0DTuw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1u6qYr-00000004I7U-1nnC; Mon, 21 Apr 2025 12:47:45 +0000 Received: from m.syntacore.com ([178.249.69.228]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1u6qYn-00000004I6f-3tLy for opensbi@lists.infradead.org; Mon, 21 Apr 2025 12:47:43 +0000 Received: from pmg.syntacore.com (localhost.localdomain [127.0.0.1]) by m.syntacore.com (Proxmox) with ESMTP id 622C8B41C98 for <opensbi@lists.infradead.org>; Mon, 21 Apr 2025 15:47:39 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=syntacore.com; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:message-id:mime-version:reply-to:subject:subject :to:to; s=m; bh=HzIsBnhhB+9QjP9NkkdZEf9jV+uIQ8AX1Qvy7iJkIz8=; b= GDzSJuW1jwFJTNBTRoiuVMVB+I0iJ9hQeDHzxog4UiM8/WA9IbC+la3xCiNpAF6f pUmK/7Vle9v/PA5hWN0kYxpqonAs4sDkyw3Y5velmGA65PvsWTvpY7t6m53odru4 YxyYpMyVS/ArSAaZ8EKiWKTMa4tKwDwAaaE0/BI2Fsqh7guTqJKKIDcbccSgehQz LhqrifMbAqSteYbr/x0VNP6VVxi3cTcuaT5UlL4gQJoKKZhmM4ynhrDmMXWofReC n8JekIrvkdK/AGwnidjC5dMLscWr9Dqq1rmpvLcSuM/ws6smaJFuMKoPk5IsvdDY ZnX8Gmf0TL17M/TgEA9TkQ== Received: from S-SC-EXCH-01.corp.syntacore.com (exchange.syntacore.com [10.76.202.20]) by m.syntacore.com (Proxmox) with ESMTPS id 44E1AB41BF3 for <opensbi@lists.infradead.org>; Mon, 21 Apr 2025 15:47:39 +0300 (MSK) Received: from ouran.high.school.host.club (172.17.15.172) by S-SC-EXCH-01.corp.syntacore.com (10.76.202.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 21 Apr 2025 15:46:16 +0300 From: Parshintsev Anatoly <anatoly.parshintsev@syntacore.com> To: <opensbi@lists.infradead.org> CC: Parshintsev Anatoly <anatoly.parshintsev@syntacore.com> Subject: [PATCH] fix missing .debug_frame DWARF section if gcc-based toolchain is used Date: Mon, 21 Apr 2025 15:47:29 +0300 Message-ID: <20250421124729.36364-1-anatoly.parshintsev@syntacore.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-Originating-IP: [172.17.15.172] X-ClientProxiedBy: S-SC-EXCH-01.corp.syntacore.com (10.76.202.20) To S-SC-EXCH-01.corp.syntacore.com (10.76.202.20) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250421_054742_133617_74092D93 X-CRM114-Status: GOOD ( 11.30 ) X-Spam-Score: -2.1 (--) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: When OpenSBI is built with a relatively new compiler (gcc-13 and greater) I observed that GDB is unable to produce proper backtraces and some variable values appear corrupted (even if the associated D [...] Content analysis details: (-2.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [178.249.69.228 listed in sa-trusted.bondedsender.org] 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [178.249.69.228 listed in sa-accredit.habeas.com] 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [178.249.69.228 listed in bl.score.senderscore.com] X-BeenThere: opensbi@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: <opensbi.lists.infradead.org> List-Unsubscribe: <http://lists.infradead.org/mailman/options/opensbi>, <mailto:opensbi-request@lists.infradead.org?subject=unsubscribe> List-Archive: <http://lists.infradead.org/pipermail/opensbi/> List-Post: <mailto:opensbi@lists.infradead.org> List-Help: <mailto:opensbi-request@lists.infradead.org?subject=help> List-Subscribe: <http://lists.infradead.org/mailman/listinfo/opensbi>, <mailto:opensbi-request@lists.infradead.org?subject=subscribe> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "opensbi" <opensbi-bounces@lists.infradead.org> Errors-To: opensbi-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org |
Series |
fix missing .debug_frame DWARF section if gcc-based toolchain is used
|
expand
|
diff --git a/Makefile b/Makefile index e90836c..85748bc 100644 --- a/Makefile +++ b/Makefile @@ -362,6 +362,7 @@ GENFLAGS += $(firmware-genflags-y) CFLAGS = -g -Wall -Werror -ffreestanding -nostdlib -fno-stack-protector -fno-strict-aliasing -ffunction-sections -fdata-sections CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls +CFLAGS += -fno-asynchronous-unwind-tables -fno-unwind-tables # Optionally supported flags ifeq ($(CC_SUPPORT_VECTOR),y) CFLAGS += -DOPENSBI_CC_SUPPORT_VECTOR
When OpenSBI is built with a relatively new compiler (gcc-13 and greater) I observed that GDB is unable to produce proper backtraces and some variable values appear corrupted (even if the associated DWARF location descriptor is correct). Turns out that to properly work with debug information, debuggers often need to unwind the stack. They generally rely on Call Frame Information (CFI) records provided by the compiler to facilitate this task. Currently, the GCC compiler offers two mechanisms: - `.debug_frame` section (as described in the DWARF specification). - `.eh_frame` sections (as described in LSB documents). The latter (`.eh_frame`) supports stack unwinding at runtime, providing a framework for C++ exceptions or enabling backtrace generation using libraries like libunwind. However, the downside of this approach is that these sections should be part of loadable segments. The former (`.debug_frame`) is simply an ordinary debug section. Starting from GCC 13, Linux targets enable the `-fasynchronous-unwind-tables` and `-funwind-tables` flags by default. Relevant commit: https://github.com/gcc-mirror/gcc/commit/3cd08f7168 When these flags are active, the compiler generates `.eh_frame` sections instead of `.debug_frame`. Since OpenSBI is built using the **Linux toolchain**, this behavior applies to OpenSBI as well. The problem arises because the SBI build system uses `-Wl,--gc-sections`, which discards the `.eh_frame` section. Possible Fixes: 1. Enforce `.debug_frame` generation – Modify compiler flags to generate `.debug_frame` instead of `.eh_frame`. 2. Preserve `.eh_frame` in the linker script – Add `KEEP(*(.eh_frame))` to ensure the section is not discarded. I chose Option 1 because it avoids any runtime overhead. Signed-off-by: Parshintsev Anatoly <anatoly.parshintsev@syntacore.com> --- Makefile | 1 + 1 file changed, 1 insertion(+)