From: Tianyi Liu <i.pear@outlook.com>
To: jpoimboe@kernel.org
Cc: acme@kernel.org, alan.maguire@oracle.com, alexandref75@gmail.com,
bpf@vger.kernel.org, dxu@dxuuu.xyz, i.pear@outlook.com,
jforbes@redhat.com, linux-kernel@vger.kernel.org,
olsajiri@gmail.com, peterz@infradead.org, ptalbert@redhat.com,
yhs@fb.com
Subject: Re: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes
Date: Wed, 12 Apr 2023 15:10:14 +0800 [thread overview]
Message-ID: <SY4P282MB10847ED9277ECA2E7B8A52779D9B9@SY4P282MB1084.AUSP282.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20230411170058.7677oximl7oq4hkv@treble>
On Tue, Apr 11, 2023 at 17:00 , Josh Poimboeuf wrote:
> 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?
>
Josh, first of all, thank you very much for your help. However, this patch
doesn't work in my environment. I am using gcc 12.2.1 20230201.
After compiling, when I use readelf -S to view ELF sections,
the align of .notes section is still 8:
$ readelf -S .tmp_vmlinux.btf
[20] .notes NOTE ffffffff8250b570 0170b570
0000000000000084 0000000000000000 A 0 0 8
> 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?
>
It has been fixed in dwarves[1], but it may just be a coincidence.
> [1] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2346#note_1348057786
>
> ---8<---
>
> From: Josh Poimboeuf <jpoimboe@kernel.org>
> 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 <dxu@dxuuu.xyz>
> Debugged-by: Tianyi Liu <i.pear@outlook.com>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> ---
> 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
[1] https://github.com/acmel/dwarves/commit/a9498899109d3be14f17abbc322a8f55a1067bee
next prev parent reply other threads:[~2023-04-12 7:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAMHq1ZuhecqT-YX8+yzUyhx8tmnQ7CDyuXV4GOuG=z44XTFsaw@mail.gmail.com>
[not found] ` <SY4P282MB1084A0E31D4228DF89FC42639DA29@SY4P282MB1084.AUSP282.PROD.OUTLOOK.COM>
2023-04-11 17:00 ` Josh Poimboeuf
2023-04-12 7:10 ` Tianyi Liu [this message]
2023-04-12 16:30 ` Josh Poimboeuf
2023-04-13 2:21 ` Joan Bruguera Micó
2023-04-13 9:23 ` Tianyi Liu
2023-04-13 18:59 ` [PATCH] vmlinux.lds.h: Discard .note.gnu.property section Josh Poimboeuf
2023-04-16 19:02 ` Joan Bruguera Micó
2023-04-18 21:47 ` Josh Poimboeuf
2023-04-18 21:49 ` [PATCH v2] " Josh Poimboeuf
2023-04-13 4:54 ` [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes Tianyi Liu
2023-04-16 18:52 ` Joan Bruguera Micó
2023-04-27 5:14 ` Joan Bruguera Micó
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SY4P282MB10847ED9277ECA2E7B8A52779D9B9@SY4P282MB1084.AUSP282.PROD.OUTLOOK.COM \
--to=i.pear@outlook.com \
--cc=acme@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=alexandref75@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=dxu@dxuuu.xyz \
--cc=jforbes@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olsajiri@gmail.com \
--cc=peterz@infradead.org \
--cc=ptalbert@redhat.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®