From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAACB3B6BF7 for ; Tue, 28 Jul 2026 12:43:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785242591; cv=none; b=QDJg+ZoTeZyrSBsjFjYlqmZTDWN6oRKQWQRcut5+rwjDTxDQCADwc7vPuZc6wC0N7qiFmwPDW1/30zaYMSo/J8uK0HvbaN2f/sPRV3wDQty/w9rjKJGw5XrqXd8OLetNl25L1Erj5na8ay+WVpIusEB7yxqbt1IJb+hWlNqkc5c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785242591; c=relaxed/simple; bh=sISaQzaH+VTpRnyWAc2SlIPqhjf3NMP0c2WTav+LdKw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=m0XbtqZInVc/P8Ma66EcVqV5YbLIoT49YGWFXuNEmyFNxYk6DXBTQHhxz8XeKygICZvPt8Go+nxo6OIXie4fpZx8XhV2htxoyn4YuLF/FuI3w5K3o4Vl/6e2SLB6qP77MPa9ZTA6O2Jt3zBYtvKboTrfYEhVpU9MLTAVA0QvwJM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=JlxFSg65; arc=none smtp.client-ip=209.85.218.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="JlxFSg65" Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-c167aa9500dso504637066b.3 for ; Tue, 28 Jul 2026 05:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1785242588; x=1785847388; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=WrFF5zeJa6i3dJjxCwt2P+w1tBuT5VdStKupxsyRdtc=; b=JlxFSg65GKZ+Rtpc2wyo/SOs8G3NhIJypruIwE4Ub0lxRXml9dbbFMGas96SnPNxOn d3/dDHVNgzbQ+AZlCf/TDYqBQ0n9QqX2gdFcp1DQzfbweXbFzSkN/XgTTT2snsQc2m2N 1KrxElcFKIyUgGdroeeBjTUrQyO7W3CMlVji0YCE24tXOxfJmMuYjW9SBNte5unWVnko IU1X3siu/clQaPNZCC9PrLwBVeS4RvK7ToqvyptVkLAhz7emFw78d6xEbel03AsfXh+i m1G3ht0J06FGfjIc3dnnACiFd51Am5Ljcfe5q1EMXDW/gZFz4ZkxOFp9gWD25EkcaPj4 7xuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785242588; x=1785847388; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=WrFF5zeJa6i3dJjxCwt2P+w1tBuT5VdStKupxsyRdtc=; b=iQ7vqA0W3Nr2nTwsHvBhokuobyYktRXmjaXOg0BIy0HQeXwmuBYrbddOHAUHBOApsf 2p61cAvj6GW495WiDUFZ2m9UooiIYp6RjsZvaNTlfWe/Ez614MD5xdNyhB9izCROrKKX F46uDAZacZZK2UZpgUpi0RjxtUSeed1ivNufAfvUI5BTrINm8+3xpm1Q2J2sJ8n0POnU 4VWGq6KzalLX4h52er7uLKBFnFc32H0gdpBuRl5JAxcrC6x8MR/cuXRFSvU5hdzs+Y1r f7AFaNgKw4LzbUd6WVJ89O4BxU2EKf6DfMv3++vYC/p7cLTaBvAa53I/FdIr/yhSkvF5 BlOQ== X-Forwarded-Encrypted: i=1; AHgh+RrET6nCC2JM+fd9STQOd/YlfL5W7bvMw+ze83SvcXEayUD2jdSt3Nqz2HbDFb7PufUbpx6Tykl4uGg9xUE=@vger.kernel.org X-Gm-Message-State: AOJu0YyAv1Dd86vrP9HkKUEHPNf7+t/dxlHY6VTvKda5ymzrh0/c0fC7 q5JFZyDOxy8WBuxfERJOGcL/5/I0WaW1Uy1+gUxuAhuWrlQyekNSBMzU9px0o9hGBs8= X-Gm-Gg: AR+sD11PejhuTdRvRIUEnopaiXqpNaplqbH70VBaU48SeD/VgkwnxupnbWjx7vPdouK /K49fOGRgiAsq+u5ei/GQnwCVwxZ+XN2uBNmTYo8E+zyW7seqy/r/q0dS1YrxicSPsqxkUfPxQo tLAIJW5m3VyruKPDwxmNgD3GPGUXALGONBK3aZokZk50dloSOKJHAOUHSsP8AjIEpvGqfroeR+b HdXM0+A6Qcw0g0Nl2X+mRTM89sXY7SJBPP9UT7k1TiahVA4EAdY/QlZKBNHPCDSkQUFp7cASB19 bQU32Kxh7Uv7OgdUpX5ZDZjpJIPn0a1HTgzgzakbmgHG0EZzGDiDcWzplCVquDCTjpV+UopjGxc DU1V2RIKyCYaBfz2ZY7AqPLCN392H7qqBtzsncS+id29E+v6MbN5kzLUJdu5E5TrRMAU98p99Kb EsnFaWr1QssYnhEiryXXz/L6TgQnlr7A/65w6161I8rFX/Cr5vmmu9Jam6yV9sqRU6ew== X-Received: by 2002:a17:907:8dcd:b0:c1f:6f31:2880 with SMTP id a640c23a62f3a-c1f721507c1mr116075766b.50.1785242587931; Tue, 28 Jul 2026 05:43:07 -0700 (PDT) Received: from puffmais2.c.googlers.com (150.230.32.34.bc.googleusercontent.com. [34.32.230.150]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1c32c902d2sm745805766b.34.2026.07.28.05.43.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 05:43:07 -0700 (PDT) From: =?utf-8?q?Andr=C3=A9_Draszik?= Date: Tue, 28 Jul 2026 13:42:40 +0100 Subject: [PATCH 2/2] kbuild: link-vmlinux.sh: improve detection of third pass requirement Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20260728-linux-kallsyms-fix-v1-2-1a665156c898@linaro.org> References: <20260728-linux-kallsyms-fix-v1-0-1a665156c898@linaro.org> In-Reply-To: <20260728-linux-kallsyms-fix-v1-0-1a665156c898@linaro.org> To: Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt Cc: Peter Griffin , Tudor Ambarus , Juan Yescas , Guenter Roeck , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, llvm@lists.linux.dev, =?utf-8?q?Andr=C3=A9_Draszik?= X-Mailer: b4 0.14.3 It can happen that symbol sizes within .tmp_vmlinux1.kallsyms.o and .tmp_vmlinux2.kallsyms.o differ, without affecting file size on disk because of section alignment and/or padding emitted by the assembler. link-vmlinux.sh doesn't detect this case currently and keeps using .tmp_vmlinux2.kallsyms.o to link the final vmlinux. Due to the different symbol sizes, other symbols are shifted within the final image compared to .tmp_vmlinux2, and the final comparison of System.map against "${kallsyms_sysmap}" fails with the message: Inconsistent kallsyms data Try "make KALLSYMS_EXTRA_PASS=1" as a workaround This can happen in particular if the linker emits additional symbols that might have different names between our (re-)linking steps, e.g. because those names depend on the virtual address of the symbol. Linker stubs for ARM errata work-arounds are one such case. These changed symbol names can cause the output of the token compression of kallsyms.c to change due to the changed symbol substring count, which in turn can change the size of the kallsyms_names symbol itself, causing the potential shift of subsequent symbol addresses in .tmp_vmlinux2.kallsyms.o and therefore the final image. Update link-vmlinux.sh to not rely on file size of .tmp_vmlinux?.kallsyms.o alone but to also consider symbol offsets within to resolve this, and do a third pass if required. Signed-off-by: André Draszik --- The issue was hitting: In a build with CONFIG_ARM64_ERRATUM_843419=y, the linker adds numerous instances of __CortexA53843419_ stubs (LLVM in my case). As the second part of the symbol name depends on the virtual address of the stub target, it changes between .tmp_vmlinux1 and .tmp_vmlinux2. This change made kallsyms_names bigger by one byte: - .byte 0x1c, 0x74, 0xff, 0x43, 0xb9, 0xc3, 0x78, 0x41, 0x35, 0x33, 0x38, 0x34, 0x33, 0x34, 0x31, 0x39, 0x5f, 0x1a, 0x1a, 0x1a, 0x43, 0x30, 0x38, 0x33, 0x41, 0x1a, 0x30, 0x30, 0x34 /* t__CortexA53843419_FFFFFFC083AFF004 */ + .byte 0x1d, 0x74, 0xff, 0x43, 0xb9, 0xc3, 0x78, 0x41, 0x35, 0x33, 0x38, 0x34, 0x33, 0x34, 0x31, 0x39, 0x5f, 0x1a, 0x1a, 0x1a, 0x43, 0x30, 0x38, 0x34, 0x38, 0x38, 0x46, 0x30, 0x30, 0x34 /* t__CortexA53843419_FFFFFFC08488F004 */ and grew the total size of kallsyms_names from 3879944 to 3879945 bytes. Since this moved it past the four byte alignment, all subsequent symbols were shifted by 4 bytes, causing the final sanity check to fail. $ stat -c'%s' .tmp_vmlinux1.kallsyms.o .tmp_vmlinux2.kallsyms.o 18458168 18458168 $ diff -u <(nm -n .tmp_vmlinux1.kallsyms.o) <(nm -n .tmp_vmlinux2.kallsyms.o) --- /dev/fd/63 2026-07-28 12:17:55.542466443 +0100 +++ /dev/fd/62 2026-07-28 12:17:55.542466443 +0100 @@ -4,8 +4,8 @@ 0000000000000000 N $d 0000000000000000 R kallsyms_num_syms 0000000000000004 R kallsyms_names -00000000003b340c R kallsyms_markers -00000000003b50bc R kallsyms_token_table -00000000003b563c R kallsyms_token_index -00000000003b583c R kallsyms_offsets -00000000005806c8 R kallsyms_seqs_of_names +00000000003b3410 R kallsyms_markers +00000000003b50c0 R kallsyms_token_table +00000000003b5640 R kallsyms_token_index +00000000003b5840 R kallsyms_offsets +00000000005806cc R kallsyms_seqs_of_names $ size -A .tmp_vmlinux1.kallsyms.o .tmp_vmlinux2.kallsyms.o .tmp_vmlinux1.kallsyms.o : section size addr .text 0 0 .rodata 7178673 0 .debug_line 49 0 .debug_line_str 72 0 Total 7178794 .tmp_vmlinux2.kallsyms.o : section size addr .text 0 0 .rodata 7178677 0 .debug_line 49 0 .debug_line_str 72 0 Total 7178798 --- scripts/link-vmlinux.sh | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh index c8f27e4175f9..ab0b8125c8cb 100755 --- a/scripts/link-vmlinux.sh +++ b/scripts/link-vmlinux.sh @@ -106,6 +106,18 @@ vmlinux_link() ${kallsymso} ${btf_vmlinux_bin_o} ${arch_vmlinux_o} ${ldlibs} } +# Check if kallsymso_prev and kallsymso differ +# If symbol sizes within ${kallsymso} change, any symbols within vmlinux are +# likely to shift, invalidating ${kallsymso}. +# Since file size can remain unchanged even if symbol sizes change, compare the +# actual symbols instead of relying on file size only. +kallsymso_changed() +{ + ${NM} -n "${kallsymso_prev}" > "${kallsymso_prev}.sym" + ${NM} -n "${kallsymso}" > "${kallsymso}.sym" + ! cmp -s "${kallsymso_prev}.sym" "${kallsymso}.sym" +} + # Create ${2}.o file with all symbols from the ${1} object file kallsyms() { @@ -126,6 +138,7 @@ kallsyms() ${CC} ${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS} \ ${KBUILD_AFLAGS} ${KBUILD_AFLAGS_KERNEL} -c -o "${2}.o" "${2}.S" + kallsymso_prev="${kallsymso:-}" kallsymso=${2}.o } @@ -255,7 +268,12 @@ if is_enabled CONFIG_KALLSYMS; then sysmap_and_kallsyms .tmp_vmlinux2 size2=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" ${kallsymso}) - if [ $size1 -ne $size2 ] || [ -n "${KALLSYMS_EXTRA_PASS}" ]; then + # Due to alignment, file size of the kallsymso object file might remain + # unchanged even if individual symbols within change size. Changed + # symbol sizes can still shift other symbols, though. Therefore, don't + # rely on file size alone. + if [ $size1 -ne $size2 ] || kallsymso_changed || \ + [ -n "${KALLSYMS_EXTRA_PASS}" ]; then vmlinux_link .tmp_vmlinux3 sysmap_and_kallsyms .tmp_vmlinux3 fi -- 2.55.0.229.g6434b31f56-goog