Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp5813421rwl; Tue, 11 Apr 2023 10:15:35 -0700 (PDT) X-Google-Smtp-Source: AKy350ZFwBZ4rsL8CYt57FTdy49/9XtH9YMgyoc2q3roIa4X/VkB8Tx0jjqy92ZYrd9dZlpZNRq7 X-Received: by 2002:a17:902:f683:b0:19a:b427:230a with SMTP id l3-20020a170902f68300b0019ab427230amr15305241plg.63.1681233334438; Tue, 11 Apr 2023 10:15:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681233334; cv=none; d=google.com; s=arc-20160816; b=G1kCniPmoV6lzyfFIMkqkg/RUDWisrsgbPM/I9AMhQmNteJ52nJx1UdjYHXcwRzKro l4BCJFNC2JjgrHhYrmuQ7MPg1pb2c8QocoPkdAyUIVqpExe2NhVNOYWpKyTXIVrFVlKd +BCTnAJp0XyHPu52YMgbVE/lrZ4paB2ZOKDDonmzZs01V0/YI3rE7MkHAS7JZGXzDbE0 kKqynqKVbNo306lznCiqwfWiEjsfA9R4sSqjBymlHCo4T87RbLEAGfX2S+LNv/g2LLKY pAC8Ebr/IjKyJy9j0fw8OaJ8EFrDJV6HYEPRgSTD0MN8jqxzt269DmyNHtBCJhJr8P9r r+Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=V5XGcSgUSF6qGYqMjkfyPPBePXfR0h46h0d2jE/asEs=; b=nZJzJlE9XOMNKvIQq3o6E8+526b9G5DPB0kX85KEL2yqhRXsoJ0mNoHr3w4V33iBpO t8U138zJCDQpHz/1PtAUxnEvYTTZqNZ/YyAVSqcuxdeErOrvj11iEE81ZzX3Xz5rU4hx WqElKDB14rvG6mCmu/DwSHH1eaBzjQl/St31y+FAh+UqJzFbgFe3RaTNgjtt+oy5UmfN PGLCjt/fkmUr0Nrg0u0kg9HDT/mm1Kbbht9yT4h1YlksQhnNM3mMJBjwjYwl472tpMbu JW4J1MoCnwaRqsU9C7+8ejAWw1PRQbBL/ugFnOMv0oEUt1xOTGNsb3hQR0VJlUZiXPyA D91w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=A1uvHVnB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kn4-20020a170903078400b001a6454116c5si2000398plb.166.2023.04.11.10.15.20; Tue, 11 Apr 2023 10:15:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=A1uvHVnB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230102AbjDKRCA (ORCPT + 99 others); Tue, 11 Apr 2023 13:02:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230042AbjDKRBc (ORCPT ); Tue, 11 Apr 2023 13:01:32 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2217D6A4E; Tue, 11 Apr 2023 10:01:13 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D54BE6299C; Tue, 11 Apr 2023 17:01:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4CE1C433EF; Tue, 11 Apr 2023 17:00:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681232460; bh=Xq8P+RD4YgDPuo3ptNv5j3i63DAD9z61+4UfucIts88=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A1uvHVnBIa+ewJJn3ce/1LScENzWOjjNFJ7xOuNkKnD5tBjmLqBQYHbZ/lfrtjOnB Bhli5Wg5iHhLt4nqjEboJ0mW5I7PjDqkdLPw2SlbRgphQPTPNOLenpbgKXpM9c2wZQ fq+RA2cp+rjlqmmcZdpI2EaoeLRvgJBkiKo3Xqp9Ej2Dv412aMQhJEfDzl9jFwA4B2 vD/g6k/cK1YQ0dYgf2M1mqPmt3ZmFZ1xHQpsrCe3VsWFYDSwVU4ISr8f4AdE/TLRM5 b/jI99QSnJezUKx+qDqV3yyC3hUo2E2IwKiXHKIXafnsCC2kif3Fpzftsz/mRbOqCR 2CojejthgVHPA== Date: Tue, 11 Apr 2023 10:00:58 -0700 From: Josh Poimboeuf To: Tianyi Liu Cc: alexandref75@gmail.com, olsajiri@gmail.com, acme@kernel.org, alan.maguire@oracle.com, bpf@vger.kernel.org, dxu@dxuuu.xyz, yhs@fb.com, Peter Zijlstra , linux-kernel@vger.kernel.org, ptalbert@redhat.com, jforbes@redhat.com Subject: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes Message-ID: <20230411170058.7677oximl7oq4hkv@treble> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 14, 2023 at 02:33:02PM +0800, Tianyi Liu wrote: > > LLVM_OBJCOPY=objcopy pahole -J --btf_gen_floats -j > > --skip_encoding_btf_inconsistent_proto --btf_gen_optimized > > .tmp_vmlinux.btf > > btf_encoder__encode: btf__dedup failed! > > Failed to encode BTF > > > > Thanks, > > > > I encountered the same problem when building a new kernel and I found some > reasons for the error. > > In short, enabling CONFIG_X86_KERNEL_IBT will change the order of records in > .notes section. In addition, due to historical problems, the alignment of > records in the .notes section is not unified, which leads to the inability of > gelf_getnote() to read the records after the wrong one. Alexandre, Tianyi, are you still seeing this issue with the latest dwarves? If so can you confirm the below patch fixes it? Apparently the latest dwarves release fixes it on Fedora Rawhide [1], does anybody know if there a specific dwarves and/or libbpf change for this? [1] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2346#note_1348057786 ---8<--- From: Josh Poimboeuf Subject: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes When tooling reads ELF notes, it assumes each note entry is aligned to the value listed in the .note section header's sh_addralign field. The kernel-created ELF notes in the .note.Linux and .note.Xen sections are aligned to 4 bytes. This causes the toolchain to set those sections' sh_addralign values to 4. On the other hand, the GCC-created .note.gnu.property section has an sh_addralign value of 8 for some reason, despite being based on struct Elf32_Nhdr which only needs 4-byte alignment. When the mismatched input sections get linked together into the vmlinux .notes output section, the higher alignment "wins", resulting in an sh_addralign of 8, which confuses tooling. For example: $ readelf -n .tmp_vmlinux.btf ... readelf: .tmp_vmlinux.btf: Warning: note with invalid namesz and/or descsz found at offset 0x170 readelf: .tmp_vmlinux.btf: Warning: type: 0x4, namesize: 0x006e6558, descsize: 0x00008801, alignment: 8 In this case readelf thinks there's alignment padding where there is none, so it starts reading an ELF note in the middle. With newer toolchains (e.g., latest Fedora Rawhide), a similar mismatch triggers a build failure when combined with CONFIG_X86_KERNEL_IBT: btf_encoder__encode: btf__dedup failed! Failed to encode BTF libbpf: failed to find '.BTF' ELF section in vmlinux FAILED: load BTF from vmlinux: No data available make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255 Fix it by forcing the .notes section input and output alignments to 4 to match the kernel's note entry alignments. Note this doesn't break the 8-byte-aligned .note.gnu.property entries because their internal data representations fill the entire 8-byte alignment boundary, so there's no padding between entries to be misinterpreted. And there's only a single entry in that section anyway. Reported-by: Daniel Xu Debugged-by: Tianyi Liu Signed-off-by: Josh Poimboeuf --- include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index d1f57e4868ed..1c7c87c9ae71 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -894,7 +894,7 @@ */ #define NOTES \ /DISCARD/ : { *(.note.GNU-stack) } \ - .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \ + .notes ALIGN(4) : AT(ADDR(.notes) - LOAD_OFFSET) SUBALIGN(4) { \ BOUNDED_SECTION_BY(.note.*, _notes) \ } NOTES_HEADERS \ NOTES_HEADERS_RESTORE -- 2.39.2