* Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
@ 2023-01-22 17:48 Daniel Xu
2023-01-22 21:25 ` Daniel Xu
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Daniel Xu @ 2023-01-22 17:48 UTC (permalink / raw)
To: bpf; +Cc: Arnaldo Carvalho de Melo
Hi,
I'm getting the following error during build:
$ ./tools/testing/selftests/bpf/vmtest.sh -j30
[...]
BTF .btf.vmlinux.bin.o
btf_encoder__encode: btf__dedup failed!
Failed to encode BTF
LD .tmp_vmlinux.kallsyms1
NM .tmp_vmlinux.kallsyms1.syms
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
NM .tmp_vmlinux.kallsyms2.syms
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.S
LD .tmp_vmlinux.kallsyms3
NM .tmp_vmlinux.kallsyms3.syms
KSYMS .tmp_vmlinux.kallsyms3.S
AS .tmp_vmlinux.kallsyms3.S
LD vmlinux
BTFIDS vmlinux
FAILED: load BTF from vmlinux: No such file or directory
make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
make[1]: *** Deleting file 'vmlinux'
make: *** [Makefile:1264: vmlinux] Error 2
This happens on both bpf-next/master (84150795a49) and 6.2-rc5
(2241ab53cb).
I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
upstream pahole on master (02d67c5176) and upstream pahole on
next (2ca56f4c6f659).
Of the above 6 combinations, I think I've tried all of them (maybe
missing 1 or 2).
Looks like GCC got updated recently on my machine, so perhaps
it's related?
CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
I'll try some debugging, but just wanted to report it first.
Thanks,
Daniel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-22 17:48 Kernel build fail with 'btf_encoder__encode: btf__dedup failed!' Daniel Xu
@ 2023-01-22 21:25 ` Daniel Xu
2023-01-23 8:06 ` Jiri Olsa
2023-05-18 11:00 ` [tip: objtool/urgent] vmlinux.lds.h: Discard .note.gnu.property section tip-bot2 for Josh Poimboeuf
2 siblings, 0 replies; 30+ messages in thread
From: Daniel Xu @ 2023-01-22 21:25 UTC (permalink / raw)
To: bpf; +Cc: Arnaldo Carvalho de Melo
On Sun, Jan 22, 2023, at 10:48 AM, Daniel Xu wrote:
> Hi,
>
> I'm getting the following error during build:
>
> $ ./tools/testing/selftests/bpf/vmtest.sh -j30
> [...]
> BTF .btf.vmlinux.bin.o
> btf_encoder__encode: btf__dedup failed!
> Failed to encode BTF
> LD .tmp_vmlinux.kallsyms1
> NM .tmp_vmlinux.kallsyms1.syms
> KSYMS .tmp_vmlinux.kallsyms1.S
> AS .tmp_vmlinux.kallsyms1.S
> LD .tmp_vmlinux.kallsyms2
> NM .tmp_vmlinux.kallsyms2.syms
> KSYMS .tmp_vmlinux.kallsyms2.S
> AS .tmp_vmlinux.kallsyms2.S
> LD .tmp_vmlinux.kallsyms3
> NM .tmp_vmlinux.kallsyms3.syms
> KSYMS .tmp_vmlinux.kallsyms3.S
> AS .tmp_vmlinux.kallsyms3.S
> LD vmlinux
> BTFIDS vmlinux
> FAILED: load BTF from vmlinux: No such file or directory
> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
> make[1]: *** Deleting file 'vmlinux'
> make: *** [Makefile:1264: vmlinux] Error 2
>
> This happens on both bpf-next/master (84150795a49) and 6.2-rc5
> (2241ab53cb).
>
> I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
> upstream pahole on master (02d67c5176) and upstream pahole on
> next (2ca56f4c6f659).
>
> Of the above 6 combinations, I think I've tried all of them (maybe
> missing 1 or 2).
>
> Looks like GCC got updated recently on my machine, so perhaps
> it's related?
>
> CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>
> I'll try some debugging, but just wanted to report it first.
>
> Thanks,
> Daniel
Applying the following diff:
diff --git a/src/btf.c b/src/btf.c
index ae1520f..8a2fa36 100644
--- a/src/btf.c
+++ b/src/btf.c
@@ -4576,8 +4576,11 @@ static int btf_dedup_ref_type(struct btf_dedup *d, __u32 type_id)
int ref_type_id;
long h;
- if (d->map[type_id] == BTF_IN_PROGRESS_ID)
+ if (d->map[type_id] == BTF_IN_PROGRESS_ID) {
+ struct btf_type *t = btf_type_by_id(d->btf, type_id);
+ pr_warn("eloop type_id=%d, kind=%d, type=%d\n", type_id, btf_kind(t), t->type);
return -ELOOP;
+ }
if (d->map[type_id] <= BTF_MAX_NR_TYPES)
return resolve_type_id(d, type_id);
Yields:
BTF .btf.vmlinux.bin.o
libbpf: eloop type_id=2, kind=10, type=2
btf_encoder__encode: btf__dedup failed!
Failed to encode BTF
So it's a CONST pointing to itself?
I'm somewhat out of ideas here.
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-22 17:48 Kernel build fail with 'btf_encoder__encode: btf__dedup failed!' Daniel Xu
2023-01-22 21:25 ` Daniel Xu
@ 2023-01-23 8:06 ` Jiri Olsa
2023-01-24 6:13 ` Daniel Xu
2023-05-18 11:00 ` [tip: objtool/urgent] vmlinux.lds.h: Discard .note.gnu.property section tip-bot2 for Josh Poimboeuf
2 siblings, 1 reply; 30+ messages in thread
From: Jiri Olsa @ 2023-01-23 8:06 UTC (permalink / raw)
To: Daniel Xu; +Cc: bpf, Arnaldo Carvalho de Melo
On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
> Hi,
>
> I'm getting the following error during build:
>
> $ ./tools/testing/selftests/bpf/vmtest.sh -j30
> [...]
> BTF .btf.vmlinux.bin.o
> btf_encoder__encode: btf__dedup failed!
> Failed to encode BTF
> LD .tmp_vmlinux.kallsyms1
> NM .tmp_vmlinux.kallsyms1.syms
> KSYMS .tmp_vmlinux.kallsyms1.S
> AS .tmp_vmlinux.kallsyms1.S
> LD .tmp_vmlinux.kallsyms2
> NM .tmp_vmlinux.kallsyms2.syms
> KSYMS .tmp_vmlinux.kallsyms2.S
> AS .tmp_vmlinux.kallsyms2.S
> LD .tmp_vmlinux.kallsyms3
> NM .tmp_vmlinux.kallsyms3.syms
> KSYMS .tmp_vmlinux.kallsyms3.S
> AS .tmp_vmlinux.kallsyms3.S
> LD vmlinux
> BTFIDS vmlinux
> FAILED: load BTF from vmlinux: No such file or directory
> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
> make[1]: *** Deleting file 'vmlinux'
> make: *** [Makefile:1264: vmlinux] Error 2
>
> This happens on both bpf-next/master (84150795a49) and 6.2-rc5
> (2241ab53cb).
>
> I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
> upstream pahole on master (02d67c5176) and upstream pahole on
> next (2ca56f4c6f659).
>
> Of the above 6 combinations, I think I've tried all of them (maybe
> missing 1 or 2).
>
> Looks like GCC got updated recently on my machine, so perhaps
> it's related?
>
> CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>
> I'll try some debugging, but just wanted to report it first.
hi,
I can't reproduce that.. can you reproduce it outside vmtest.sh?
there will be lot of output with patch below, but could contain
some more error output
jirka
---
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 32e573943cf0..05ac3ced89e7 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -125,7 +125,7 @@ gen_btf()
vmlinux_link ${1}
info "BTF" ${2}
- LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -J ${PAHOLE_FLAGS} ${1}
+ LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -V -J ${PAHOLE_FLAGS} ${1}
# Create ${2} which contains just .BTF section but no symbols. Add
# SHF_ALLOC because .BTF will be part of the vmlinux image. --strip-all
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-23 8:06 ` Jiri Olsa
@ 2023-01-24 6:13 ` Daniel Xu
2023-01-27 22:28 ` Alexandre Peixoto Ferreira
0 siblings, 1 reply; 30+ messages in thread
From: Daniel Xu @ 2023-01-24 6:13 UTC (permalink / raw)
To: Jiri Olsa; +Cc: bpf, Arnaldo Carvalho de Melo
Hi Jiri,
On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
> On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
>> Hi,
>>
>> I'm getting the following error during build:
>>
>> $ ./tools/testing/selftests/bpf/vmtest.sh -j30
>> [...]
>> BTF .btf.vmlinux.bin.o
>> btf_encoder__encode: btf__dedup failed!
>> Failed to encode BTF
>> LD .tmp_vmlinux.kallsyms1
>> NM .tmp_vmlinux.kallsyms1.syms
>> KSYMS .tmp_vmlinux.kallsyms1.S
>> AS .tmp_vmlinux.kallsyms1.S
>> LD .tmp_vmlinux.kallsyms2
>> NM .tmp_vmlinux.kallsyms2.syms
>> KSYMS .tmp_vmlinux.kallsyms2.S
>> AS .tmp_vmlinux.kallsyms2.S
>> LD .tmp_vmlinux.kallsyms3
>> NM .tmp_vmlinux.kallsyms3.syms
>> KSYMS .tmp_vmlinux.kallsyms3.S
>> AS .tmp_vmlinux.kallsyms3.S
>> LD vmlinux
>> BTFIDS vmlinux
>> FAILED: load BTF from vmlinux: No such file or directory
>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>> make[1]: *** Deleting file 'vmlinux'
>> make: *** [Makefile:1264: vmlinux] Error 2
>>
>> This happens on both bpf-next/master (84150795a49) and 6.2-rc5
>> (2241ab53cb).
>>
>> I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
>> upstream pahole on master (02d67c5176) and upstream pahole on
>> next (2ca56f4c6f659).
>>
>> Of the above 6 combinations, I think I've tried all of them (maybe
>> missing 1 or 2).
>>
>> Looks like GCC got updated recently on my machine, so perhaps
>> it's related?
>>
>> CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>>
>> I'll try some debugging, but just wanted to report it first.
>
> hi,
> I can't reproduce that.. can you reproduce it outside vmtest.sh?
>
> there will be lot of output with patch below, but could contain
> some more error output
Thanks for the hints. Doing a regular build outside of vmtest.sh
seems to work ok. So maybe it's a difference in the build config.
I'll put a little more time into debugging to see if it goes anywhere.
But I'll have to get back to the regularly scheduled programming
soon.
[...]
Thanks,
Daniel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-24 6:13 ` Daniel Xu
@ 2023-01-27 22:28 ` Alexandre Peixoto Ferreira
2023-01-28 0:00 ` Jiri Olsa
0 siblings, 1 reply; 30+ messages in thread
From: Alexandre Peixoto Ferreira @ 2023-01-27 22:28 UTC (permalink / raw)
To: Daniel Xu, Jiri Olsa; +Cc: bpf, Arnaldo Carvalho de Melo
On 1/24/23 00:13, Daniel Xu wrote:
> Hi Jiri,
>
> On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
>> On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
>>> Hi,
>>>
>>> I'm getting the following error during build:
>>>
>>> $ ./tools/testing/selftests/bpf/vmtest.sh -j30
>>> [...]
>>> BTF .btf.vmlinux.bin.o
>>> btf_encoder__encode: btf__dedup failed!
>>> Failed to encode BTF
>>> LD .tmp_vmlinux.kallsyms1
>>> NM .tmp_vmlinux.kallsyms1.syms
>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>> AS .tmp_vmlinux.kallsyms1.S
>>> LD .tmp_vmlinux.kallsyms2
>>> NM .tmp_vmlinux.kallsyms2.syms
>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>> AS .tmp_vmlinux.kallsyms2.S
>>> LD .tmp_vmlinux.kallsyms3
>>> NM .tmp_vmlinux.kallsyms3.syms
>>> KSYMS .tmp_vmlinux.kallsyms3.S
>>> AS .tmp_vmlinux.kallsyms3.S
>>> LD vmlinux
>>> BTFIDS vmlinux
>>> FAILED: load BTF from vmlinux: No such file or directory
>>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>> make[1]: *** Deleting file 'vmlinux'
>>> make: *** [Makefile:1264: vmlinux] Error 2
>>>
>>> This happens on both bpf-next/master (84150795a49) and 6.2-rc5
>>> (2241ab53cb).
>>>
>>> I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
>>> upstream pahole on master (02d67c5176) and upstream pahole on
>>> next (2ca56f4c6f659).
>>>
>>> Of the above 6 combinations, I think I've tried all of them (maybe
>>> missing 1 or 2).
>>>
>>> Looks like GCC got updated recently on my machine, so perhaps
>>> it's related?
>>>
>>> CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>>>
>>> I'll try some debugging, but just wanted to report it first.
>> hi,
>> I can't reproduce that.. can you reproduce it outside vmtest.sh?
>>
>> there will be lot of output with patch below, but could contain
>> some more error output
> Thanks for the hints. Doing a regular build outside of vmtest.sh
> seems to work ok. So maybe it's a difference in the build config.
>
> I'll put a little more time into debugging to see if it goes anywhere.
> But I'll have to get back to the regularly scheduled programming
> soon.
6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but
fails in pahole when CONFIG_X86_KERNEL_IBT is set.
Thanks,
--
Alexandre Peixoto Ferreira
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-27 22:28 ` Alexandre Peixoto Ferreira
@ 2023-01-28 0:00 ` Jiri Olsa
2023-01-28 0:21 ` Daniel Xu
2023-01-28 19:23 ` Alexandre Peixoto Ferreira
0 siblings, 2 replies; 30+ messages in thread
From: Jiri Olsa @ 2023-01-28 0:00 UTC (permalink / raw)
To: Alexandre Peixoto Ferreira
Cc: Daniel Xu, Jiri Olsa, bpf, Arnaldo Carvalho de Melo
On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
>
>
> On 1/24/23 00:13, Daniel Xu wrote:
> > Hi Jiri,
> >
> > On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
> > > On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
> > > > Hi,
> > > >
> > > > I'm getting the following error during build:
> > > >
> > > > $ ./tools/testing/selftests/bpf/vmtest.sh -j30
> > > > [...]
> > > > BTF .btf.vmlinux.bin.o
> > > > btf_encoder__encode: btf__dedup failed!
> > > > Failed to encode BTF
> > > > LD .tmp_vmlinux.kallsyms1
> > > > NM .tmp_vmlinux.kallsyms1.syms
> > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > AS .tmp_vmlinux.kallsyms1.S
> > > > LD .tmp_vmlinux.kallsyms2
> > > > NM .tmp_vmlinux.kallsyms2.syms
> > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > AS .tmp_vmlinux.kallsyms2.S
> > > > LD .tmp_vmlinux.kallsyms3
> > > > NM .tmp_vmlinux.kallsyms3.syms
> > > > KSYMS .tmp_vmlinux.kallsyms3.S
> > > > AS .tmp_vmlinux.kallsyms3.S
> > > > LD vmlinux
> > > > BTFIDS vmlinux
> > > > FAILED: load BTF from vmlinux: No such file or directory
> > > > make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
> > > > make[1]: *** Deleting file 'vmlinux'
> > > > make: *** [Makefile:1264: vmlinux] Error 2
> > > >
> > > > This happens on both bpf-next/master (84150795a49) and 6.2-rc5
> > > > (2241ab53cb).
> > > >
> > > > I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
> > > > upstream pahole on master (02d67c5176) and upstream pahole on
> > > > next (2ca56f4c6f659).
> > > >
> > > > Of the above 6 combinations, I think I've tried all of them (maybe
> > > > missing 1 or 2).
> > > >
> > > > Looks like GCC got updated recently on my machine, so perhaps
> > > > it's related?
> > > >
> > > > CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
> > > >
> > > > I'll try some debugging, but just wanted to report it first.
> > > hi,
> > > I can't reproduce that.. can you reproduce it outside vmtest.sh?
> > >
> > > there will be lot of output with patch below, but could contain
> > > some more error output
> > Thanks for the hints. Doing a regular build outside of vmtest.sh
> > seems to work ok. So maybe it's a difference in the build config.
> >
> > I'll put a little more time into debugging to see if it goes anywhere.
> > But I'll have to get back to the regularly scheduled programming
> > soon.
> 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
> in pahole when CONFIG_X86_KERNEL_IBT is set.
could you plese attach your config and the build error?
I can't reproduce that
thanks,
jirka
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-28 0:00 ` Jiri Olsa
@ 2023-01-28 0:21 ` Daniel Xu
2023-01-28 0:23 ` Daniel Xu
2023-01-28 19:23 ` Alexandre Peixoto Ferreira
1 sibling, 1 reply; 30+ messages in thread
From: Daniel Xu @ 2023-01-28 0:21 UTC (permalink / raw)
To: Jiri Olsa, Alexandre Peixoto Ferreira; +Cc: bpf, Arnaldo Carvalho de Melo
Hi Jiri & Alexandre,
On Fri, Jan 27, 2023, at 5:00 PM, Jiri Olsa wrote:
> On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
>>
>>
>> On 1/24/23 00:13, Daniel Xu wrote:
>> > Hi Jiri,
>> >
>> > On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
>> > > On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
>> > > > Hi,
>> > > >
>> > > > I'm getting the following error during build:
>> > > >
>> > > > $ ./tools/testing/selftests/bpf/vmtest.sh -j30
>> > > > [...]
>> > > > BTF .btf.vmlinux.bin.o
>> > > > btf_encoder__encode: btf__dedup failed!
>> > > > Failed to encode BTF
>> > > > LD .tmp_vmlinux.kallsyms1
>> > > > NM .tmp_vmlinux.kallsyms1.syms
>> > > > KSYMS .tmp_vmlinux.kallsyms1.S
>> > > > AS .tmp_vmlinux.kallsyms1.S
>> > > > LD .tmp_vmlinux.kallsyms2
>> > > > NM .tmp_vmlinux.kallsyms2.syms
>> > > > KSYMS .tmp_vmlinux.kallsyms2.S
>> > > > AS .tmp_vmlinux.kallsyms2.S
>> > > > LD .tmp_vmlinux.kallsyms3
>> > > > NM .tmp_vmlinux.kallsyms3.syms
>> > > > KSYMS .tmp_vmlinux.kallsyms3.S
>> > > > AS .tmp_vmlinux.kallsyms3.S
>> > > > LD vmlinux
>> > > > BTFIDS vmlinux
>> > > > FAILED: load BTF from vmlinux: No such file or directory
>> > > > make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>> > > > make[1]: *** Deleting file 'vmlinux'
>> > > > make: *** [Makefile:1264: vmlinux] Error 2
>> > > >
>> > > > This happens on both bpf-next/master (84150795a49) and 6.2-rc5
>> > > > (2241ab53cb).
>> > > >
>> > > > I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
>> > > > upstream pahole on master (02d67c5176) and upstream pahole on
>> > > > next (2ca56f4c6f659).
>> > > >
>> > > > Of the above 6 combinations, I think I've tried all of them (maybe
>> > > > missing 1 or 2).
>> > > >
>> > > > Looks like GCC got updated recently on my machine, so perhaps
>> > > > it's related?
>> > > >
>> > > > CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>> > > >
>> > > > I'll try some debugging, but just wanted to report it first.
>> > > hi,
>> > > I can't reproduce that.. can you reproduce it outside vmtest.sh?
>> > >
>> > > there will be lot of output with patch below, but could contain
>> > > some more error output
>> > Thanks for the hints. Doing a regular build outside of vmtest.sh
>> > seems to work ok. So maybe it's a difference in the build config.
>> >
>> > I'll put a little more time into debugging to see if it goes anywhere.
>> > But I'll have to get back to the regularly scheduled programming
>> > soon.
>> 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
>> in pahole when CONFIG_X86_KERNEL_IBT is set.
>
> could you plese attach your config and the build error?
> I can't reproduce that
I've confirmed that CONFIG_X86_KERNEL_IBT=n fixes my issue as well.
Here is the config that produces my originally reported error:
https://pastes.dxuuu.xyz/wlg9tb
Thanks,
Daniel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-28 0:21 ` Daniel Xu
@ 2023-01-28 0:23 ` Daniel Xu
0 siblings, 0 replies; 30+ messages in thread
From: Daniel Xu @ 2023-01-28 0:23 UTC (permalink / raw)
To: Jiri Olsa, Alexandre Peixoto Ferreira; +Cc: bpf, Arnaldo Carvalho de Melo
On Fri, Jan 27, 2023, at 5:21 PM, Daniel Xu wrote:
> Hi Jiri & Alexandre,
>
> On Fri, Jan 27, 2023, at 5:00 PM, Jiri Olsa wrote:
>> On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
>>>
>>>
>>> On 1/24/23 00:13, Daniel Xu wrote:
>>> > Hi Jiri,
>>> >
>>> > On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
>>> > > On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
>>> > > > Hi,
>>> > > >
>>> > > > I'm getting the following error during build:
>>> > > >
>>> > > > $ ./tools/testing/selftests/bpf/vmtest.sh -j30
>>> > > > [...]
>>> > > > BTF .btf.vmlinux.bin.o
>>> > > > btf_encoder__encode: btf__dedup failed!
>>> > > > Failed to encode BTF
>>> > > > LD .tmp_vmlinux.kallsyms1
>>> > > > NM .tmp_vmlinux.kallsyms1.syms
>>> > > > KSYMS .tmp_vmlinux.kallsyms1.S
>>> > > > AS .tmp_vmlinux.kallsyms1.S
>>> > > > LD .tmp_vmlinux.kallsyms2
>>> > > > NM .tmp_vmlinux.kallsyms2.syms
>>> > > > KSYMS .tmp_vmlinux.kallsyms2.S
>>> > > > AS .tmp_vmlinux.kallsyms2.S
>>> > > > LD .tmp_vmlinux.kallsyms3
>>> > > > NM .tmp_vmlinux.kallsyms3.syms
>>> > > > KSYMS .tmp_vmlinux.kallsyms3.S
>>> > > > AS .tmp_vmlinux.kallsyms3.S
>>> > > > LD vmlinux
>>> > > > BTFIDS vmlinux
>>> > > > FAILED: load BTF from vmlinux: No such file or directory
>>> > > > make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>> > > > make[1]: *** Deleting file 'vmlinux'
>>> > > > make: *** [Makefile:1264: vmlinux] Error 2
>>> > > >
>>> > > > This happens on both bpf-next/master (84150795a49) and 6.2-rc5
>>> > > > (2241ab53cb).
>>> > > >
>>> > > > I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
>>> > > > upstream pahole on master (02d67c5176) and upstream pahole on
>>> > > > next (2ca56f4c6f659).
>>> > > >
>>> > > > Of the above 6 combinations, I think I've tried all of them (maybe
>>> > > > missing 1 or 2).
>>> > > >
>>> > > > Looks like GCC got updated recently on my machine, so perhaps
>>> > > > it's related?
>>> > > >
>>> > > > CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>>> > > >
>>> > > > I'll try some debugging, but just wanted to report it first.
>>> > > hi,
>>> > > I can't reproduce that.. can you reproduce it outside vmtest.sh?
>>> > >
>>> > > there will be lot of output with patch below, but could contain
>>> > > some more error output
>>> > Thanks for the hints. Doing a regular build outside of vmtest.sh
>>> > seems to work ok. So maybe it's a difference in the build config.
>>> >
>>> > I'll put a little more time into debugging to see if it goes anywhere.
>>> > But I'll have to get back to the regularly scheduled programming
>>> > soon.
>>> 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
>>> in pahole when CONFIG_X86_KERNEL_IBT is set.
>>
>> could you plese attach your config and the build error?
>> I can't reproduce that
>
> I've confirmed that CONFIG_X86_KERNEL_IBT=n fixes my issue as well.
>
> Here is the config that produces my originally reported error:
> https://pastes.dxuuu.xyz/wlg9tb
>
> Thanks,
> Daniel
Here's a patch that helps for me. Not sure if you want to apply this or fix
the root cause in bpftool.
---
From 3dc50f3dd45767cb8c3b32c1510c7064f20f80c1 Mon Sep 17 00:00:00 2001
Message-Id: <3dc50f3dd45767cb8c3b32c1510c7064f20f80c1.1674865319.git.dxu@dxuuu.xyz>
From: Daniel Xu <dxu@dxuuu.xyz>
Date: Fri, 27 Jan 2023 17:17:32 -0700
Subject: [PATCH] bpf, selftests: Disable CONFIG_X86_KERNEL_IBT for vmtest.sh
CONFIG_X86_KERNEL_IBT=y was causing the following compile error:
BTF .btf.vmlinux.bin.o
btf_encoder__encode: btf__dedup failed!
Failed to encode BTF
LD .tmp_vmlinux.kallsyms1
NM .tmp_vmlinux.kallsyms1.syms
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
NM .tmp_vmlinux.kallsyms2.syms
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.S
LD .tmp_vmlinux.kallsyms3
NM .tmp_vmlinux.kallsyms3.syms
KSYMS .tmp_vmlinux.kallsyms3.S
AS .tmp_vmlinux.kallsyms3.S
LD vmlinux
BTFIDS vmlinux
libbpf: failed to find '.BTF' ELF section in vmlinux
FAILED: load BTF from vmlinux: No data available
make[1]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 255
make[1]: *** Deleting file 'vmlinux'
make: *** [Makefile:1252: vmlinux] Error 2
Disable for vmtests as we do not really need the extra security measures
there.
I suspect this was recently triggered by
4fd5f70ce14d ("x86/Kconfig: Enable kernel IBT by default").
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
---
tools/testing/selftests/bpf/config.x86_64 | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/bpf/config.x86_64 b/tools/testing/selftests/bpf/config.x86_64
index dd97d61d325c..3026b1282cc7 100644
--- a/tools/testing/selftests/bpf/config.x86_64
+++ b/tools/testing/selftests/bpf/config.x86_64
@@ -237,6 +237,7 @@ CONFIG_VIRTIO_PCI=y
CONFIG_VLAN_8021Q=y
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_CPUID=y
+CONFIG_X86_KERNEL_IBT=n
CONFIG_X86_MSR=y
CONFIG_X86_POWERNOW_K8=y
CONFIG_XDP_SOCKETS_DIAG=y
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-28 0:00 ` Jiri Olsa
2023-01-28 0:21 ` Daniel Xu
@ 2023-01-28 19:23 ` Alexandre Peixoto Ferreira
2023-01-31 15:18 ` Jiri Olsa
1 sibling, 1 reply; 30+ messages in thread
From: Alexandre Peixoto Ferreira @ 2023-01-28 19:23 UTC (permalink / raw)
To: Jiri Olsa; +Cc: Daniel Xu, bpf, Arnaldo Carvalho de Melo
Jirka and Daniel,
On 1/27/23 18:00, Jiri Olsa wrote:
> On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
>>
>> On 1/24/23 00:13, Daniel Xu wrote:
>>> Hi Jiri,
>>>
>>> On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
>>>> On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
>>>>> Hi,
>>>>>
>>>>> I'm getting the following error during build:
>>>>>
>>>>> $ ./tools/testing/selftests/bpf/vmtest.sh -j30
>>>>> [...]
>>>>> BTF .btf.vmlinux.bin.o
>>>>> btf_encoder__encode: btf__dedup failed!
>>>>> Failed to encode BTF
>>>>> LD .tmp_vmlinux.kallsyms1
>>>>> NM .tmp_vmlinux.kallsyms1.syms
>>>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>>>> AS .tmp_vmlinux.kallsyms1.S
>>>>> LD .tmp_vmlinux.kallsyms2
>>>>> NM .tmp_vmlinux.kallsyms2.syms
>>>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>>>> AS .tmp_vmlinux.kallsyms2.S
>>>>> LD .tmp_vmlinux.kallsyms3
>>>>> NM .tmp_vmlinux.kallsyms3.syms
>>>>> KSYMS .tmp_vmlinux.kallsyms3.S
>>>>> AS .tmp_vmlinux.kallsyms3.S
>>>>> LD vmlinux
>>>>> BTFIDS vmlinux
>>>>> FAILED: load BTF from vmlinux: No such file or directory
>>>>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>>>> make[1]: *** Deleting file 'vmlinux'
>>>>> make: *** [Makefile:1264: vmlinux] Error 2
>>>>>
>>>>> This happens on both bpf-next/master (84150795a49) and 6.2-rc5
>>>>> (2241ab53cb).
>>>>>
>>>>> I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
>>>>> upstream pahole on master (02d67c5176) and upstream pahole on
>>>>> next (2ca56f4c6f659).
>>>>>
>>>>> Of the above 6 combinations, I think I've tried all of them (maybe
>>>>> missing 1 or 2).
>>>>>
>>>>> Looks like GCC got updated recently on my machine, so perhaps
>>>>> it's related?
>>>>>
>>>>> CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>>>>>
>>>>> I'll try some debugging, but just wanted to report it first.
>>>> hi,
>>>> I can't reproduce that.. can you reproduce it outside vmtest.sh?
>>>>
>>>> there will be lot of output with patch below, but could contain
>>>> some more error output
>>> Thanks for the hints. Doing a regular build outside of vmtest.sh
>>> seems to work ok. So maybe it's a difference in the build config.
>>>
>>> I'll put a little more time into debugging to see if it goes anywhere.
>>> But I'll have to get back to the regularly scheduled programming
>>> soon.
>> 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
>> in pahole when CONFIG_X86_KERNEL_IBT is set.
> could you plese attach your config and the build error?
> I can't reproduce that
>
> thanks,
> jirka
My working .config is available at https://pastebin.pl/view/bef3765c
change CONFIG_X86_KERNEL_IBT to y to get the error.
The error is similar to Daniel's and is shown below:
LD .tmp_vmlinux.btf
BTF .btf.vmlinux.bin.o
btf_encoder__encode: btf__dedup failed!
Failed to encode BTF
LD .tmp_vmlinux.kallsyms1
NM .tmp_vmlinux.kallsyms1.syms
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
NM .tmp_vmlinux.kallsyms2.syms
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.S
LD .tmp_vmlinux.kallsyms3
NM .tmp_vmlinux.kallsyms3.syms
KSYMS .tmp_vmlinux.kallsyms3.S
AS .tmp_vmlinux.kallsyms3.S
LD vmlinux
BTFIDS vmlinux
FAILED: load BTF from vmlinux: No such file or directory
make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
make[1]: *** Deleting file 'vmlinux'
make: *** [Makefile:1264: vmlinux] Error 2
Thanks,
--
Alexandre Peixoto Ferreira
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-28 19:23 ` Alexandre Peixoto Ferreira
@ 2023-01-31 15:18 ` Jiri Olsa
2023-02-09 0:21 ` Vicki Pfau
2023-02-09 4:15 ` Alexandre Peixoto Ferreira
0 siblings, 2 replies; 30+ messages in thread
From: Jiri Olsa @ 2023-01-31 15:18 UTC (permalink / raw)
To: Alexandre Peixoto Ferreira
Cc: Jiri Olsa, Daniel Xu, bpf, Arnaldo Carvalho de Melo
On Sat, Jan 28, 2023 at 01:23:25PM -0600, Alexandre Peixoto Ferreira wrote:
> Jirka and Daniel,
>
> On 1/27/23 18:00, Jiri Olsa wrote:
> > On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
> > >
> > > On 1/24/23 00:13, Daniel Xu wrote:
> > > > Hi Jiri,
> > > >
> > > > On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
> > > > > On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'm getting the following error during build:
> > > > > >
> > > > > > $ ./tools/testing/selftests/bpf/vmtest.sh -j30
> > > > > > [...]
> > > > > > BTF .btf.vmlinux.bin.o
> > > > > > btf_encoder__encode: btf__dedup failed!
> > > > > > Failed to encode BTF
> > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > NM .tmp_vmlinux.kallsyms1.syms
> > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > NM .tmp_vmlinux.kallsyms2.syms
> > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > LD .tmp_vmlinux.kallsyms3
> > > > > > NM .tmp_vmlinux.kallsyms3.syms
> > > > > > KSYMS .tmp_vmlinux.kallsyms3.S
> > > > > > AS .tmp_vmlinux.kallsyms3.S
> > > > > > LD vmlinux
> > > > > > BTFIDS vmlinux
> > > > > > FAILED: load BTF from vmlinux: No such file or directory
> > > > > > make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
> > > > > > make[1]: *** Deleting file 'vmlinux'
> > > > > > make: *** [Makefile:1264: vmlinux] Error 2
> > > > > >
> > > > > > This happens on both bpf-next/master (84150795a49) and 6.2-rc5
> > > > > > (2241ab53cb).
> > > > > >
> > > > > > I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
> > > > > > upstream pahole on master (02d67c5176) and upstream pahole on
> > > > > > next (2ca56f4c6f659).
> > > > > >
> > > > > > Of the above 6 combinations, I think I've tried all of them (maybe
> > > > > > missing 1 or 2).
> > > > > >
> > > > > > Looks like GCC got updated recently on my machine, so perhaps
> > > > > > it's related?
> > > > > >
> > > > > > CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
> > > > > >
> > > > > > I'll try some debugging, but just wanted to report it first.
> > > > > hi,
> > > > > I can't reproduce that.. can you reproduce it outside vmtest.sh?
> > > > >
> > > > > there will be lot of output with patch below, but could contain
> > > > > some more error output
> > > > Thanks for the hints. Doing a regular build outside of vmtest.sh
> > > > seems to work ok. So maybe it's a difference in the build config.
> > > >
> > > > I'll put a little more time into debugging to see if it goes anywhere.
> > > > But I'll have to get back to the regularly scheduled programming
> > > > soon.
> > > 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
> > > in pahole when CONFIG_X86_KERNEL_IBT is set.
> > could you plese attach your config and the build error?
> > I can't reproduce that
> >
> > thanks,
> > jirka
>
> My working .config is available at https://pastebin.pl/view/bef3765c
> change CONFIG_X86_KERNEL_IBT to y to get the error.
>
> The error is similar to Daniel's and is shown below:
>
> LD .tmp_vmlinux.btf
> BTF .btf.vmlinux.bin.o
> btf_encoder__encode: btf__dedup failed!
> Failed to encode BTF
> LD .tmp_vmlinux.kallsyms1
> NM .tmp_vmlinux.kallsyms1.syms
> KSYMS .tmp_vmlinux.kallsyms1.S
> AS .tmp_vmlinux.kallsyms1.S
> LD .tmp_vmlinux.kallsyms2
> NM .tmp_vmlinux.kallsyms2.syms
> KSYMS .tmp_vmlinux.kallsyms2.S
> AS .tmp_vmlinux.kallsyms2.S
> LD .tmp_vmlinux.kallsyms3
> NM .tmp_vmlinux.kallsyms3.syms
> KSYMS .tmp_vmlinux.kallsyms3.S
> AS .tmp_vmlinux.kallsyms3.S
> LD vmlinux
> BTFIDS vmlinux
> FAILED: load BTF from vmlinux: No such file or directory
> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
> make[1]: *** Deleting file 'vmlinux'
> make: *** [Makefile:1264: vmlinux] Error 2
I can't reproduce that.. I tried with gcc versions:
gcc (GCC) 13.0.1 20230117 (Red Hat 13.0.1-0)
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
I haven't found fedora setup with 12.2.1 20230111 yet
I tried alsa with latest pahole master branch
were you guys able to get any more verbose output
that I suggested earlier?
jirka
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-31 15:18 ` Jiri Olsa
@ 2023-02-09 0:21 ` Vicki Pfau
2023-02-09 4:15 ` Alexandre Peixoto Ferreira
1 sibling, 0 replies; 30+ messages in thread
From: Vicki Pfau @ 2023-02-09 0:21 UTC (permalink / raw)
To: Jiri Olsa
Cc: Alexandre Peixoto Ferreira, Jiri Olsa, Daniel Xu, bpf,
Arnaldo Carvalho de Melo
Hello,
I seem to be having a related problem trying to build Linux at all. This used
to work, but after some recent upgrades (I am also running Arch Linux), I'm
getting a dedup error too. I'm also getting a "relocation to !ENDBR" error
that, as far as I can tell (and that's not particularly far, to be fair), is
erroneous, which makes me think something even stranger is going on with my
tools. Since both of these issues appeared, so far, only on Arch Linux, it
might be an Arch-speciifc packaging issue.
I've uploaded my config and pahole log to the following URLs:
https://endrift.com/files/config.gz
https://endrift.com/files/make-log.xz
Vicki
PS: My apologies for the lack of a quoted reply or any other formatting issues;
I'm not subscribed to this mailing list and am struggling to figure out how to
send a reply without the originals in my client. In retrospect, maybe I could
have imported the .eml/mbox directly.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-01-31 15:18 ` Jiri Olsa
2023-02-09 0:21 ` Vicki Pfau
@ 2023-02-09 4:15 ` Alexandre Peixoto Ferreira
2023-02-09 13:07 ` Alan Maguire
1 sibling, 1 reply; 30+ messages in thread
From: Alexandre Peixoto Ferreira @ 2023-02-09 4:15 UTC (permalink / raw)
To: Jiri Olsa; +Cc: Daniel Xu, bpf, Arnaldo Carvalho de Melo
Jiri,
On 1/31/23 09:18, Jiri Olsa wrote:
> On Sat, Jan 28, 2023 at 01:23:25PM -0600, Alexandre Peixoto Ferreira wrote:
>> Jirka and Daniel,
>>
>> On 1/27/23 18:00, Jiri Olsa wrote:
>>> On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
>>>> On 1/24/23 00:13, Daniel Xu wrote:
>>>>> Hi Jiri,
>>>>>
>>>>> On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
>>>>>> On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm getting the following error during build:
>>>>>>>
>>>>>>> $ ./tools/testing/selftests/bpf/vmtest.sh -j30
>>>>>>> [...]
>>>>>>> BTF .btf.vmlinux.bin.o
>>>>>>> btf_encoder__encode: btf__dedup failed!
>>>>>>> Failed to encode BTF
>>>>>>> LD .tmp_vmlinux.kallsyms1
>>>>>>> NM .tmp_vmlinux.kallsyms1.syms
>>>>>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>>>>>> AS .tmp_vmlinux.kallsyms1.S
>>>>>>> LD .tmp_vmlinux.kallsyms2
>>>>>>> NM .tmp_vmlinux.kallsyms2.syms
>>>>>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>>>>>> AS .tmp_vmlinux.kallsyms2.S
>>>>>>> LD .tmp_vmlinux.kallsyms3
>>>>>>> NM .tmp_vmlinux.kallsyms3.syms
>>>>>>> KSYMS .tmp_vmlinux.kallsyms3.S
>>>>>>> AS .tmp_vmlinux.kallsyms3.S
>>>>>>> LD vmlinux
>>>>>>> BTFIDS vmlinux
>>>>>>> FAILED: load BTF from vmlinux: No such file or directory
>>>>>>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>>>>>> make[1]: *** Deleting file 'vmlinux'
>>>>>>> make: *** [Makefile:1264: vmlinux] Error 2
>>>>>>>
>>>>>>> This happens on both bpf-next/master (84150795a49) and 6.2-rc5
>>>>>>> (2241ab53cb).
>>>>>>>
>>>>>>> I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
>>>>>>> upstream pahole on master (02d67c5176) and upstream pahole on
>>>>>>> next (2ca56f4c6f659).
>>>>>>>
>>>>>>> Of the above 6 combinations, I think I've tried all of them (maybe
>>>>>>> missing 1 or 2).
>>>>>>>
>>>>>>> Looks like GCC got updated recently on my machine, so perhaps
>>>>>>> it's related?
>>>>>>>
>>>>>>> CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>>>>>>>
>>>>>>> I'll try some debugging, but just wanted to report it first.
>>>>>> hi,
>>>>>> I can't reproduce that.. can you reproduce it outside vmtest.sh?
>>>>>>
>>>>>> there will be lot of output with patch below, but could contain
>>>>>> some more error output
>>>>> Thanks for the hints. Doing a regular build outside of vmtest.sh
>>>>> seems to work ok. So maybe it's a difference in the build config.
>>>>>
>>>>> I'll put a little more time into debugging to see if it goes anywhere.
>>>>> But I'll have to get back to the regularly scheduled programming
>>>>> soon.
>>>> 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
>>>> in pahole when CONFIG_X86_KERNEL_IBT is set.
>>> could you plese attach your config and the build error?
>>> I can't reproduce that
>>>
>>> thanks,
>>> jirka
>> My working .config is available at https://pastebin.pl/view/bef3765c
>> change CONFIG_X86_KERNEL_IBT to y to get the error.
>>
>> The error is similar to Daniel's and is shown below:
>>
>> LD .tmp_vmlinux.btf
>> BTF .btf.vmlinux.bin.o
>> btf_encoder__encode: btf__dedup failed!
>> Failed to encode BTF
>> LD .tmp_vmlinux.kallsyms1
>> NM .tmp_vmlinux.kallsyms1.syms
>> KSYMS .tmp_vmlinux.kallsyms1.S
>> AS .tmp_vmlinux.kallsyms1.S
>> LD .tmp_vmlinux.kallsyms2
>> NM .tmp_vmlinux.kallsyms2.syms
>> KSYMS .tmp_vmlinux.kallsyms2.S
>> AS .tmp_vmlinux.kallsyms2.S
>> LD .tmp_vmlinux.kallsyms3
>> NM .tmp_vmlinux.kallsyms3.syms
>> KSYMS .tmp_vmlinux.kallsyms3.S
>> AS .tmp_vmlinux.kallsyms3.S
>> LD vmlinux
>> BTFIDS vmlinux
>> FAILED: load BTF from vmlinux: No such file or directory
>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>> make[1]: *** Deleting file 'vmlinux'
>> make: *** [Makefile:1264: vmlinux] Error 2
> I can't reproduce that.. I tried with gcc versions:
>
> gcc (GCC) 13.0.1 20230117 (Red Hat 13.0.1-0)
> gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
>
> I haven't found fedora setup with 12.2.1 20230111 yet
>
> I tried alsa with latest pahole master branch
>
> were you guys able to get any more verbose output
> that I suggested earlier?
>
> jirka
I compiled with and without IBT using the -V on pahole
(LLVM_OBJCOPY=objcopy pahole -V -J --btf_gen_floats -j .tmp_vmlinux.btf)
and the outfiles are a little too big (540MB). The error happens with
this CONST type pointing to itself. That does not happen with the IBT
option removed.
$ grep -n "CONST (anon) type_id" /tmp/with_IBT | more
346:[2] CONST (anon) type_id=2
349:[5] CONST (anon) type_id=5
351:[7] CONST (anon) type_id=7
356:[12] CONST (anon) type_id=12
363:[19] CONST (anon) type_id=19
373:[29] CONST (anon) type_id=29
375:[31] CONST (anon) type_id=31
409:[63] CONST (anon) type_id=63
444:[89] CONST (anon) type_id=0
472:[97] CONST (anon) type_id=97
616:[129] CONST (anon) type_id=129
652:[131] CONST (anon) type_id=131
1319:[234] CONST (anon) type_id=234
1372:[246] CONST (anon) type_id=246
....
$diff -ru with_IBT without_IBT
--- with_IBT 2023-01-31 09:39:24.915912735 -0600
+++ without_IBT 2023-01-31 09:46:23.456005278 -0600
@@ -340,346 +340,14800 @@
Found per-CPU symbol 'cpu_tlbstate_shared' at address 0x2c040
Found per-CPU symbol 'mce_poll_banks' at address 0x1ad20
Found 341 per-CPU variables!
-Found 61470 functions!
+Found 61462 functions!
+File .tmp_vmlinux.btf:
+[1] FUNC_PROTO (anon) return=0 args=(void)
+[2] FUNC verify_cpu type_id=1
+[3] FUNC_PROTO (anon) return=0 args=(void)
+[4] FUNC sev_verify_cbit type_id=3
+search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
+Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
+Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
+Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
+Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
+Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
+Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
+Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
+Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
+Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
+Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
+Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
+Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
+Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
+Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
+Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
+Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
+Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
+Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
+Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
+Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
+Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
+Found per-CPU symbol 'last_nmi_rip' at address 0x1a018
+Found per-CPU symbol 'nmi_stats' at address 0x1a030
+Found per-CPU symbol 'swallow_nmi' at address 0x1a020
+Found per-CPU symbol 'nmi_state' at address 0x1a010
+Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
+Found per-CPU symbol 'nmi_cr2' at address 0x1a008
+Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
+Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
+Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
+Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
+Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
...
And the lines 342-365 of the with_IBT result:
342 Found 341 per-CPU variables!
343 Found 61470 functions!
344 File .tmp_vmlinux.btf:
345 [1] INT long unsigned int size=8 nr_bits=64 encoding=(none)
346 [2] CONST (anon) type_id=2
347 [3] PTR (anon) type_id=6
348 [4] INT char size=1 nr_bits=8 encoding=(none)
349 [5] CONST (anon) type_id=5
350 [6] INT unsigned int size=4 nr_bits=32 encoding=(none)
351 [7] CONST (anon) type_id=7
352 [8] TYPEDEF __s8 type_id=10
353 [9] INT signed char size=1 nr_bits=8 encoding=SIGNED
354 [10] TYPEDEF __u8 type_id=12
355 [11] INT unsigned char size=1 nr_bits=8 encoding=(none)
356 [12] CONST (anon) type_id=12
357 [13] TYPEDEF __s16 type_id=15
358 [14] INT short int size=2 nr_bits=16 encoding=SIGNED
359 [15] TYPEDEF __u16 type_id=17
360 [16] INT short unsigned int size=2 nr_bits=16 encoding=(none)
361 [17] TYPEDEF __s32 type_id=19
362 [18] INT int size=4 nr_bits=32 encoding=SIGNED
363 [19] CONST (anon) type_id=19
364 [20] TYPEDEF __u32 type_id=7
365 [21] TYPEDEF __s64 type_id=23
lines 342-362 of without_IBT
342 Found 341 per-CPU variables!
343 Found 61462 functions!
344 File .tmp_vmlinux.btf:
345 [1] FUNC_PROTO (anon) return=0 args=(void)
346 [2] FUNC verify_cpu type_id=1
347 [3] FUNC_PROTO (anon) return=0 args=(void)
348 [4] FUNC sev_verify_cbit type_id=3
349 search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
350 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
351 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
352 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
353 Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
354 Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
355 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
356 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
357 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
358 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
359 Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
360 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
361 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
362 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
If the full debug files are useful or a target grep or diff is better
let me know.
Thanks,
--
Alexandre Peixoto Ferreira
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-02-09 4:15 ` Alexandre Peixoto Ferreira
@ 2023-02-09 13:07 ` Alan Maguire
2023-02-10 14:02 ` Alexandre Peixoto Ferreira
0 siblings, 1 reply; 30+ messages in thread
From: Alan Maguire @ 2023-02-09 13:07 UTC (permalink / raw)
To: Alexandre Peixoto Ferreira, Jiri Olsa
Cc: Daniel Xu, bpf, Arnaldo Carvalho de Melo
On 09/02/2023 04:15, Alexandre Peixoto Ferreira wrote:
> Jiri,
>
> On 1/31/23 09:18, Jiri Olsa wrote:
>> On Sat, Jan 28, 2023 at 01:23:25PM -0600, Alexandre Peixoto Ferreira wrote:
>>> Jirka and Daniel,
>>>
>>> On 1/27/23 18:00, Jiri Olsa wrote:
>>>> On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
>>>>> On 1/24/23 00:13, Daniel Xu wrote:
>>>>>> Hi Jiri,
>>>>>>
>>>>>> On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
>>>>>>> On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm getting the following error during build:
>>>>>>>>
>>>>>>>> $ ./tools/testing/selftests/bpf/vmtest.sh -j30
>>>>>>>> [...]
>>>>>>>> BTF .btf.vmlinux.bin.o
>>>>>>>> btf_encoder__encode: btf__dedup failed!
>>>>>>>> Failed to encode BTF
>>>>>>>> LD .tmp_vmlinux.kallsyms1
>>>>>>>> NM .tmp_vmlinux.kallsyms1.syms
>>>>>>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>>>>>>> AS .tmp_vmlinux.kallsyms1.S
>>>>>>>> LD .tmp_vmlinux.kallsyms2
>>>>>>>> NM .tmp_vmlinux.kallsyms2.syms
>>>>>>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>>>>>>> AS .tmp_vmlinux.kallsyms2.S
>>>>>>>> LD .tmp_vmlinux.kallsyms3
>>>>>>>> NM .tmp_vmlinux.kallsyms3.syms
>>>>>>>> KSYMS .tmp_vmlinux.kallsyms3.S
>>>>>>>> AS .tmp_vmlinux.kallsyms3.S
>>>>>>>> LD vmlinux
>>>>>>>> BTFIDS vmlinux
>>>>>>>> FAILED: load BTF from vmlinux: No such file or directory
>>>>>>>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>>>>>>> make[1]: *** Deleting file 'vmlinux'
>>>>>>>> make: *** [Makefile:1264: vmlinux] Error 2
>>>>>>>>
>>>>>>>> This happens on both bpf-next/master (84150795a49) and 6.2-rc5
>>>>>>>> (2241ab53cb).
>>>>>>>>
>>>>>>>> I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
>>>>>>>> upstream pahole on master (02d67c5176) and upstream pahole on
>>>>>>>> next (2ca56f4c6f659).
>>>>>>>>
>>>>>>>> Of the above 6 combinations, I think I've tried all of them (maybe
>>>>>>>> missing 1 or 2).
>>>>>>>>
>>>>>>>> Looks like GCC got updated recently on my machine, so perhaps
>>>>>>>> it's related?
>>>>>>>>
>>>>>>>> CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>>>>>>>>
>>>>>>>> I'll try some debugging, but just wanted to report it first.
>>>>>>> hi,
>>>>>>> I can't reproduce that.. can you reproduce it outside vmtest.sh?
>>>>>>>
>>>>>>> there will be lot of output with patch below, but could contain
>>>>>>> some more error output
>>>>>> Thanks for the hints. Doing a regular build outside of vmtest.sh
>>>>>> seems to work ok. So maybe it's a difference in the build config.
>>>>>>
>>>>>> I'll put a little more time into debugging to see if it goes anywhere.
>>>>>> But I'll have to get back to the regularly scheduled programming
>>>>>> soon.
>>>>> 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
>>>>> in pahole when CONFIG_X86_KERNEL_IBT is set.
>>>> could you plese attach your config and the build error?
>>>> I can't reproduce that
>>>>
>>>> thanks,
>>>> jirka
>>> My working .config is available at https://pastebin.pl/view/bef3765c
>>> change CONFIG_X86_KERNEL_IBT to y to get the error.
>>>
>>> The error is similar to Daniel's and is shown below:
>>>
>>> LD .tmp_vmlinux.btf
>>> BTF .btf.vmlinux.bin.o
>>> btf_encoder__encode: btf__dedup failed!
>>> Failed to encode BTF
>>> LD .tmp_vmlinux.kallsyms1
>>> NM .tmp_vmlinux.kallsyms1.syms
>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>> AS .tmp_vmlinux.kallsyms1.S
>>> LD .tmp_vmlinux.kallsyms2
>>> NM .tmp_vmlinux.kallsyms2.syms
>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>> AS .tmp_vmlinux.kallsyms2.S
>>> LD .tmp_vmlinux.kallsyms3
>>> NM .tmp_vmlinux.kallsyms3.syms
>>> KSYMS .tmp_vmlinux.kallsyms3.S
>>> AS .tmp_vmlinux.kallsyms3.S
>>> LD vmlinux
>>> BTFIDS vmlinux
>>> FAILED: load BTF from vmlinux: No such file or directory
>>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>> make[1]: *** Deleting file 'vmlinux'
>>> make: *** [Makefile:1264: vmlinux] Error 2
>> I can't reproduce that.. I tried with gcc versions:
>>
>> gcc (GCC) 13.0.1 20230117 (Red Hat 13.0.1-0)
>> gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
>>
>> I haven't found fedora setup with 12.2.1 20230111 yet
>>
>> I tried alsa with latest pahole master branch
>>
>> were you guys able to get any more verbose output
>> that I suggested earlier?
>>
>> jirka
>
> I compiled with and without IBT using the -V on pahole (LLVM_OBJCOPY=objcopy pahole -V -J --btf_gen_floats -j .tmp_vmlinux.btf) and the outfiles are a little too big (540MB). The error happens with this CONST type pointing to itself. That does not happen with the IBT option removed.
>
> $ grep -n "CONST (anon) type_id" /tmp/with_IBT | more
> 346:[2] CONST (anon) type_id=2
> 349:[5] CONST (anon) type_id=5
> 351:[7] CONST (anon) type_id=7
> 356:[12] CONST (anon) type_id=12
> 363:[19] CONST (anon) type_id=19
> 373:[29] CONST (anon) type_id=29
> 375:[31] CONST (anon) type_id=31
> 409:[63] CONST (anon) type_id=63
> 444:[89] CONST (anon) type_id=0
> 472:[97] CONST (anon) type_id=97
> 616:[129] CONST (anon) type_id=129
> 652:[131] CONST (anon) type_id=131
> 1319:[234] CONST (anon) type_id=234
> 1372:[246] CONST (anon) type_id=246
> ....
>
> $diff -ru with_IBT without_IBT
> --- with_IBT 2023-01-31 09:39:24.915912735 -0600
> +++ without_IBT 2023-01-31 09:46:23.456005278 -0600
> @@ -340,346 +340,14800 @@
> Found per-CPU symbol 'cpu_tlbstate_shared' at address 0x2c040
> Found per-CPU symbol 'mce_poll_banks' at address 0x1ad20
> Found 341 per-CPU variables!
> -Found 61470 functions!
> +Found 61462 functions!
> +File .tmp_vmlinux.btf:
> +[1] FUNC_PROTO (anon) return=0 args=(void)
> +[2] FUNC verify_cpu type_id=1
> +[3] FUNC_PROTO (anon) return=0 args=(void)
> +[4] FUNC sev_verify_cbit type_id=3
> +search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> +Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> +Found per-CPU symbol 'last_nmi_rip' at address 0x1a018
> +Found per-CPU symbol 'nmi_stats' at address 0x1a030
> +Found per-CPU symbol 'swallow_nmi' at address 0x1a020
> +Found per-CPU symbol 'nmi_state' at address 0x1a010
> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> +Found per-CPU symbol 'nmi_cr2' at address 0x1a008
> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> ...
>
> And the lines 342-365 of the with_IBT result:
> 342 Found 341 per-CPU variables!
> 343 Found 61470 functions!
> 344 File .tmp_vmlinux.btf:
> 345 [1] INT long unsigned int size=8 nr_bits=64 encoding=(none)
> 346 [2] CONST (anon) type_id=2
> 347 [3] PTR (anon) type_id=6
> 348 [4] INT char size=1 nr_bits=8 encoding=(none)
> 349 [5] CONST (anon) type_id=5
> 350 [6] INT unsigned int size=4 nr_bits=32 encoding=(none)
> 351 [7] CONST (anon) type_id=7
> 352 [8] TYPEDEF __s8 type_id=10
> 353 [9] INT signed char size=1 nr_bits=8 encoding=SIGNED
> 354 [10] TYPEDEF __u8 type_id=12
> 355 [11] INT unsigned char size=1 nr_bits=8 encoding=(none)
> 356 [12] CONST (anon) type_id=12
> 357 [13] TYPEDEF __s16 type_id=15
> 358 [14] INT short int size=2 nr_bits=16 encoding=SIGNED
> 359 [15] TYPEDEF __u16 type_id=17
> 360 [16] INT short unsigned int size=2 nr_bits=16 encoding=(none)
> 361 [17] TYPEDEF __s32 type_id=19
> 362 [18] INT int size=4 nr_bits=32 encoding=SIGNED
> 363 [19] CONST (anon) type_id=19
> 364 [20] TYPEDEF __u32 type_id=7
> 365 [21] TYPEDEF __s64 type_id=23
>
> lines 342-362 of without_IBT
>
> 342 Found 341 per-CPU variables!
> 343 Found 61462 functions!
> 344 File .tmp_vmlinux.btf:
> 345 [1] FUNC_PROTO (anon) return=0 args=(void)
> 346 [2] FUNC verify_cpu type_id=1
> 347 [3] FUNC_PROTO (anon) return=0 args=(void)
> 348 [4] FUNC sev_verify_cbit type_id=3
> 349 search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
> 350 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> 351 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> 352 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> 353 Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> 354 Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> 355 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> 356 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> 357 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> 358 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> 359 Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
> 360 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> 361 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> 362 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>
> If the full debug files are useful or a target grep or diff is better let me know.
>
I managed to reproduce this too with IBT enabled; one thing I
noticed is with pahole built with an up-to-date libbpf and the
changes in https://github.com/acmel/dwarves/tree/next, the problem
went away. I didn't have time to root-cause it yet however.
Not sure if you're in a position to do this, but if you can,
would you mind building pahole from
https://github.com/acmel/dwarves/tree/next
...and re-testing to see if that helps? Thanks!
Alan
> Thanks,
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-02-09 13:07 ` Alan Maguire
@ 2023-02-10 14:02 ` Alexandre Peixoto Ferreira
2023-02-10 14:34 ` Jiri Olsa
0 siblings, 1 reply; 30+ messages in thread
From: Alexandre Peixoto Ferreira @ 2023-02-10 14:02 UTC (permalink / raw)
To: Alan Maguire, Jiri Olsa; +Cc: Daniel Xu, bpf, Arnaldo Carvalho de Melo
Alam,
On 2/9/23 07:07, Alan Maguire wrote:
> On 09/02/2023 04:15, Alexandre Peixoto Ferreira wrote:
>> Jiri,
>>
>> On 1/31/23 09:18, Jiri Olsa wrote:
>>> On Sat, Jan 28, 2023 at 01:23:25PM -0600, Alexandre Peixoto Ferreira wrote:
>>>> Jirka and Daniel,
>>>>
>>>> On 1/27/23 18:00, Jiri Olsa wrote:
>>>>> On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
>>>>>> On 1/24/23 00:13, Daniel Xu wrote:
>>>>>>> Hi Jiri,
>>>>>>>
>>>>>>> On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
>>>>>>>> On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm getting the following error during build:
>>>>>>>>>
>>>>>>>>> $ ./tools/testing/selftests/bpf/vmtest.sh -j30
>>>>>>>>> [...]
>>>>>>>>> BTF .btf.vmlinux.bin.o
>>>>>>>>> btf_encoder__encode: btf__dedup failed!
>>>>>>>>> Failed to encode BTF
>>>>>>>>> LD .tmp_vmlinux.kallsyms1
>>>>>>>>> NM .tmp_vmlinux.kallsyms1.syms
>>>>>>>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>>>>>>>> AS .tmp_vmlinux.kallsyms1.S
>>>>>>>>> LD .tmp_vmlinux.kallsyms2
>>>>>>>>> NM .tmp_vmlinux.kallsyms2.syms
>>>>>>>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>>>>>>>> AS .tmp_vmlinux.kallsyms2.S
>>>>>>>>> LD .tmp_vmlinux.kallsyms3
>>>>>>>>> NM .tmp_vmlinux.kallsyms3.syms
>>>>>>>>> KSYMS .tmp_vmlinux.kallsyms3.S
>>>>>>>>> AS .tmp_vmlinux.kallsyms3.S
>>>>>>>>> LD vmlinux
>>>>>>>>> BTFIDS vmlinux
>>>>>>>>> FAILED: load BTF from vmlinux: No such file or directory
>>>>>>>>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>>>>>>>> make[1]: *** Deleting file 'vmlinux'
>>>>>>>>> make: *** [Makefile:1264: vmlinux] Error 2
>>>>>>>>>
>>>>>>>>> This happens on both bpf-next/master (84150795a49) and 6.2-rc5
>>>>>>>>> (2241ab53cb).
>>>>>>>>>
>>>>>>>>> I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
>>>>>>>>> upstream pahole on master (02d67c5176) and upstream pahole on
>>>>>>>>> next (2ca56f4c6f659).
>>>>>>>>>
>>>>>>>>> Of the above 6 combinations, I think I've tried all of them (maybe
>>>>>>>>> missing 1 or 2).
>>>>>>>>>
>>>>>>>>> Looks like GCC got updated recently on my machine, so perhaps
>>>>>>>>> it's related?
>>>>>>>>>
>>>>>>>>> CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>>>>>>>>>
>>>>>>>>> I'll try some debugging, but just wanted to report it first.
>>>>>>>> hi,
>>>>>>>> I can't reproduce that.. can you reproduce it outside vmtest.sh?
>>>>>>>>
>>>>>>>> there will be lot of output with patch below, but could contain
>>>>>>>> some more error output
>>>>>>> Thanks for the hints. Doing a regular build outside of vmtest.sh
>>>>>>> seems to work ok. So maybe it's a difference in the build config.
>>>>>>>
>>>>>>> I'll put a little more time into debugging to see if it goes anywhere.
>>>>>>> But I'll have to get back to the regularly scheduled programming
>>>>>>> soon.
>>>>>> 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
>>>>>> in pahole when CONFIG_X86_KERNEL_IBT is set.
>>>>> could you plese attach your config and the build error?
>>>>> I can't reproduce that
>>>>>
>>>>> thanks,
>>>>> jirka
>>>> My working .config is available at https://pastebin.pl/view/bef3765c
>>>> change CONFIG_X86_KERNEL_IBT to y to get the error.
>>>>
>>>> The error is similar to Daniel's and is shown below:
>>>>
>>>> LD .tmp_vmlinux.btf
>>>> BTF .btf.vmlinux.bin.o
>>>> btf_encoder__encode: btf__dedup failed!
>>>> Failed to encode BTF
>>>> LD .tmp_vmlinux.kallsyms1
>>>> NM .tmp_vmlinux.kallsyms1.syms
>>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>>> AS .tmp_vmlinux.kallsyms1.S
>>>> LD .tmp_vmlinux.kallsyms2
>>>> NM .tmp_vmlinux.kallsyms2.syms
>>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>>> AS .tmp_vmlinux.kallsyms2.S
>>>> LD .tmp_vmlinux.kallsyms3
>>>> NM .tmp_vmlinux.kallsyms3.syms
>>>> KSYMS .tmp_vmlinux.kallsyms3.S
>>>> AS .tmp_vmlinux.kallsyms3.S
>>>> LD vmlinux
>>>> BTFIDS vmlinux
>>>> FAILED: load BTF from vmlinux: No such file or directory
>>>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>>> make[1]: *** Deleting file 'vmlinux'
>>>> make: *** [Makefile:1264: vmlinux] Error 2
>>> I can't reproduce that.. I tried with gcc versions:
>>>
>>> gcc (GCC) 13.0.1 20230117 (Red Hat 13.0.1-0)
>>> gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
>>>
>>> I haven't found fedora setup with 12.2.1 20230111 yet
>>>
>>> I tried alsa with latest pahole master branch
>>>
>>> were you guys able to get any more verbose output
>>> that I suggested earlier?
>>>
>>> jirka
>> I compiled with and without IBT using the -V on pahole (LLVM_OBJCOPY=objcopy pahole -V -J --btf_gen_floats -j .tmp_vmlinux.btf) and the outfiles are a little too big (540MB). The error happens with this CONST type pointing to itself. That does not happen with the IBT option removed.
>>
>> $ grep -n "CONST (anon) type_id" /tmp/with_IBT | more
>> 346:[2] CONST (anon) type_id=2
>> 349:[5] CONST (anon) type_id=5
>> 351:[7] CONST (anon) type_id=7
>> 356:[12] CONST (anon) type_id=12
>> 363:[19] CONST (anon) type_id=19
>> 373:[29] CONST (anon) type_id=29
>> 375:[31] CONST (anon) type_id=31
>> 409:[63] CONST (anon) type_id=63
>> 444:[89] CONST (anon) type_id=0
>> 472:[97] CONST (anon) type_id=97
>> 616:[129] CONST (anon) type_id=129
>> 652:[131] CONST (anon) type_id=131
>> 1319:[234] CONST (anon) type_id=234
>> 1372:[246] CONST (anon) type_id=246
>> ....
>>
>> $diff -ru with_IBT without_IBT
>> --- with_IBT 2023-01-31 09:39:24.915912735 -0600
>> +++ without_IBT 2023-01-31 09:46:23.456005278 -0600
>> @@ -340,346 +340,14800 @@
>> Found per-CPU symbol 'cpu_tlbstate_shared' at address 0x2c040
>> Found per-CPU symbol 'mce_poll_banks' at address 0x1ad20
>> Found 341 per-CPU variables!
>> -Found 61470 functions!
>> +Found 61462 functions!
>> +File .tmp_vmlinux.btf:
>> +[1] FUNC_PROTO (anon) return=0 args=(void)
>> +[2] FUNC verify_cpu type_id=1
>> +[3] FUNC_PROTO (anon) return=0 args=(void)
>> +[4] FUNC sev_verify_cbit type_id=3
>> +search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>> +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>> +Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>> +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
>> +Found per-CPU symbol 'last_nmi_rip' at address 0x1a018
>> +Found per-CPU symbol 'nmi_stats' at address 0x1a030
>> +Found per-CPU symbol 'swallow_nmi' at address 0x1a020
>> +Found per-CPU symbol 'nmi_state' at address 0x1a010
>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>> +Found per-CPU symbol 'nmi_cr2' at address 0x1a008
>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>> +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> ...
>>
>> And the lines 342-365 of the with_IBT result:
>> 342 Found 341 per-CPU variables!
>> 343 Found 61470 functions!
>> 344 File .tmp_vmlinux.btf:
>> 345 [1] INT long unsigned int size=8 nr_bits=64 encoding=(none)
>> 346 [2] CONST (anon) type_id=2
>> 347 [3] PTR (anon) type_id=6
>> 348 [4] INT char size=1 nr_bits=8 encoding=(none)
>> 349 [5] CONST (anon) type_id=5
>> 350 [6] INT unsigned int size=4 nr_bits=32 encoding=(none)
>> 351 [7] CONST (anon) type_id=7
>> 352 [8] TYPEDEF __s8 type_id=10
>> 353 [9] INT signed char size=1 nr_bits=8 encoding=SIGNED
>> 354 [10] TYPEDEF __u8 type_id=12
>> 355 [11] INT unsigned char size=1 nr_bits=8 encoding=(none)
>> 356 [12] CONST (anon) type_id=12
>> 357 [13] TYPEDEF __s16 type_id=15
>> 358 [14] INT short int size=2 nr_bits=16 encoding=SIGNED
>> 359 [15] TYPEDEF __u16 type_id=17
>> 360 [16] INT short unsigned int size=2 nr_bits=16 encoding=(none)
>> 361 [17] TYPEDEF __s32 type_id=19
>> 362 [18] INT int size=4 nr_bits=32 encoding=SIGNED
>> 363 [19] CONST (anon) type_id=19
>> 364 [20] TYPEDEF __u32 type_id=7
>> 365 [21] TYPEDEF __s64 type_id=23
>>
>> lines 342-362 of without_IBT
>>
>> 342 Found 341 per-CPU variables!
>> 343 Found 61462 functions!
>> 344 File .tmp_vmlinux.btf:
>> 345 [1] FUNC_PROTO (anon) return=0 args=(void)
>> 346 [2] FUNC verify_cpu type_id=1
>> 347 [3] FUNC_PROTO (anon) return=0 args=(void)
>> 348 [4] FUNC sev_verify_cbit type_id=3
>> 349 search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
>> 350 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> 351 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>> 352 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>> 353 Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>> 354 Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
>> 355 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> 356 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> 357 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>> 358 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>> 359 Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
>> 360 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> 361 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>> 362 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>>
>> If the full debug files are useful or a target grep or diff is better let me know.
>>
> I managed to reproduce this too with IBT enabled; one thing I
> noticed is with pahole built with an up-to-date libbpf and the
> changes in https://github.com/acmel/dwarves/tree/next, the problem
> went away. I didn't have time to root-cause it yet however.
>
> Not sure if you're in a position to do this, but if you can,
> would you mind building pahole from
>
> https://github.com/acmel/dwarves/tree/next
>
> ...and re-testing to see if that helps? Thanks!
>
> Alan
>
>> Thanks,
>>
I tried with libbpf compiled from master
https://github.com/libbpf/libbpf.git and pahole compiled from next
branch on https://github.com/acmel/dwarve with the same result.
With IBT enabled pahole fails and removing it results in a successful
kernel.
Alex,
--
Alexandre Peixoto Ferreira
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-02-10 14:02 ` Alexandre Peixoto Ferreira
@ 2023-02-10 14:34 ` Jiri Olsa
2023-02-10 15:37 ` Alexandre Ferreira
0 siblings, 1 reply; 30+ messages in thread
From: Jiri Olsa @ 2023-02-10 14:34 UTC (permalink / raw)
To: Alexandre Peixoto Ferreira
Cc: Alan Maguire, Jiri Olsa, Daniel Xu, bpf, Arnaldo Carvalho de Melo
On Fri, Feb 10, 2023 at 08:02:23AM -0600, Alexandre Peixoto Ferreira wrote:
> Alam,
>
> On 2/9/23 07:07, Alan Maguire wrote:
> > On 09/02/2023 04:15, Alexandre Peixoto Ferreira wrote:
> > > Jiri,
> > >
> > > On 1/31/23 09:18, Jiri Olsa wrote:
> > > > On Sat, Jan 28, 2023 at 01:23:25PM -0600, Alexandre Peixoto Ferreira wrote:
> > > > > Jirka and Daniel,
> > > > >
> > > > > On 1/27/23 18:00, Jiri Olsa wrote:
> > > > > > On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
> > > > > > > On 1/24/23 00:13, Daniel Xu wrote:
> > > > > > > > Hi Jiri,
> > > > > > > >
> > > > > > > > On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
> > > > > > > > > On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I'm getting the following error during build:
> > > > > > > > > >
> > > > > > > > > > $ ./tools/testing/selftests/bpf/vmtest.sh -j30
> > > > > > > > > > [...]
> > > > > > > > > > BTF .btf.vmlinux.bin.o
> > > > > > > > > > btf_encoder__encode: btf__dedup failed!
> > > > > > > > > > Failed to encode BTF
> > > > > > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > > > > > NM .tmp_vmlinux.kallsyms1.syms
> > > > > > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > > > > > NM .tmp_vmlinux.kallsyms2.syms
> > > > > > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > > > > > LD .tmp_vmlinux.kallsyms3
> > > > > > > > > > NM .tmp_vmlinux.kallsyms3.syms
> > > > > > > > > > KSYMS .tmp_vmlinux.kallsyms3.S
> > > > > > > > > > AS .tmp_vmlinux.kallsyms3.S
> > > > > > > > > > LD vmlinux
> > > > > > > > > > BTFIDS vmlinux
> > > > > > > > > > FAILED: load BTF from vmlinux: No such file or directory
> > > > > > > > > > make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
> > > > > > > > > > make[1]: *** Deleting file 'vmlinux'
> > > > > > > > > > make: *** [Makefile:1264: vmlinux] Error 2
> > > > > > > > > >
> > > > > > > > > > This happens on both bpf-next/master (84150795a49) and 6.2-rc5
> > > > > > > > > > (2241ab53cb).
> > > > > > > > > >
> > > > > > > > > > I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
> > > > > > > > > > upstream pahole on master (02d67c5176) and upstream pahole on
> > > > > > > > > > next (2ca56f4c6f659).
> > > > > > > > > >
> > > > > > > > > > Of the above 6 combinations, I think I've tried all of them (maybe
> > > > > > > > > > missing 1 or 2).
> > > > > > > > > >
> > > > > > > > > > Looks like GCC got updated recently on my machine, so perhaps
> > > > > > > > > > it's related?
> > > > > > > > > >
> > > > > > > > > > CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
> > > > > > > > > >
> > > > > > > > > > I'll try some debugging, but just wanted to report it first.
> > > > > > > > > hi,
> > > > > > > > > I can't reproduce that.. can you reproduce it outside vmtest.sh?
> > > > > > > > >
> > > > > > > > > there will be lot of output with patch below, but could contain
> > > > > > > > > some more error output
> > > > > > > > Thanks for the hints. Doing a regular build outside of vmtest.sh
> > > > > > > > seems to work ok. So maybe it's a difference in the build config.
> > > > > > > >
> > > > > > > > I'll put a little more time into debugging to see if it goes anywhere.
> > > > > > > > But I'll have to get back to the regularly scheduled programming
> > > > > > > > soon.
> > > > > > > 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
> > > > > > > in pahole when CONFIG_X86_KERNEL_IBT is set.
> > > > > > could you plese attach your config and the build error?
> > > > > > I can't reproduce that
> > > > > >
> > > > > > thanks,
> > > > > > jirka
> > > > > My working .config is available at https://pastebin.pl/view/bef3765c
> > > > > change CONFIG_X86_KERNEL_IBT to y to get the error.
> > > > >
> > > > > The error is similar to Daniel's and is shown below:
> > > > >
> > > > > LD .tmp_vmlinux.btf
> > > > > BTF .btf.vmlinux.bin.o
> > > > > btf_encoder__encode: btf__dedup failed!
> > > > > Failed to encode BTF
> > > > > LD .tmp_vmlinux.kallsyms1
> > > > > NM .tmp_vmlinux.kallsyms1.syms
> > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > LD .tmp_vmlinux.kallsyms2
> > > > > NM .tmp_vmlinux.kallsyms2.syms
> > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > LD .tmp_vmlinux.kallsyms3
> > > > > NM .tmp_vmlinux.kallsyms3.syms
> > > > > KSYMS .tmp_vmlinux.kallsyms3.S
> > > > > AS .tmp_vmlinux.kallsyms3.S
> > > > > LD vmlinux
> > > > > BTFIDS vmlinux
> > > > > FAILED: load BTF from vmlinux: No such file or directory
> > > > > make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
> > > > > make[1]: *** Deleting file 'vmlinux'
> > > > > make: *** [Makefile:1264: vmlinux] Error 2
> > > > I can't reproduce that.. I tried with gcc versions:
> > > >
> > > > gcc (GCC) 13.0.1 20230117 (Red Hat 13.0.1-0)
> > > > gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
> > > >
> > > > I haven't found fedora setup with 12.2.1 20230111 yet
> > > >
> > > > I tried alsa with latest pahole master branch
> > > >
> > > > were you guys able to get any more verbose output
> > > > that I suggested earlier?
> > > >
> > > > jirka
> > > I compiled with and without IBT using the -V on pahole (LLVM_OBJCOPY=objcopy pahole -V -J --btf_gen_floats -j .tmp_vmlinux.btf) and the outfiles are a little too big (540MB). The error happens with this CONST type pointing to itself. That does not happen with the IBT option removed.
> > >
> > > $ grep -n "CONST (anon) type_id" /tmp/with_IBT | more
> > > 346:[2] CONST (anon) type_id=2
> > > 349:[5] CONST (anon) type_id=5
> > > 351:[7] CONST (anon) type_id=7
> > > 356:[12] CONST (anon) type_id=12
> > > 363:[19] CONST (anon) type_id=19
> > > 373:[29] CONST (anon) type_id=29
> > > 375:[31] CONST (anon) type_id=31
> > > 409:[63] CONST (anon) type_id=63
> > > 444:[89] CONST (anon) type_id=0
> > > 472:[97] CONST (anon) type_id=97
> > > 616:[129] CONST (anon) type_id=129
> > > 652:[131] CONST (anon) type_id=131
> > > 1319:[234] CONST (anon) type_id=234
> > > 1372:[246] CONST (anon) type_id=246
> > > ....
> > >
> > > $diff -ru with_IBT without_IBT
> > > --- with_IBT 2023-01-31 09:39:24.915912735 -0600
> > > +++ without_IBT 2023-01-31 09:46:23.456005278 -0600
> > > @@ -340,346 +340,14800 @@
> > > Found per-CPU symbol 'cpu_tlbstate_shared' at address 0x2c040
> > > Found per-CPU symbol 'mce_poll_banks' at address 0x1ad20
> > > Found 341 per-CPU variables!
> > > -Found 61470 functions!
> > > +Found 61462 functions!
> > > +File .tmp_vmlinux.btf:
> > > +[1] FUNC_PROTO (anon) return=0 args=(void)
> > > +[2] FUNC verify_cpu type_id=1
> > > +[3] FUNC_PROTO (anon) return=0 args=(void)
> > > +[4] FUNC sev_verify_cbit type_id=3
> > > +search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
> > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > +Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
> > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> > > +Found per-CPU symbol 'last_nmi_rip' at address 0x1a018
> > > +Found per-CPU symbol 'nmi_stats' at address 0x1a030
> > > +Found per-CPU symbol 'swallow_nmi' at address 0x1a020
> > > +Found per-CPU symbol 'nmi_state' at address 0x1a010
> > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > +Found per-CPU symbol 'nmi_cr2' at address 0x1a008
> > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > ...
> > >
> > > And the lines 342-365 of the with_IBT result:
> > > 342 Found 341 per-CPU variables!
> > > 343 Found 61470 functions!
> > > 344 File .tmp_vmlinux.btf:
> > > 345 [1] INT long unsigned int size=8 nr_bits=64 encoding=(none)
> > > 346 [2] CONST (anon) type_id=2
> > > 347 [3] PTR (anon) type_id=6
> > > 348 [4] INT char size=1 nr_bits=8 encoding=(none)
> > > 349 [5] CONST (anon) type_id=5
> > > 350 [6] INT unsigned int size=4 nr_bits=32 encoding=(none)
> > > 351 [7] CONST (anon) type_id=7
> > > 352 [8] TYPEDEF __s8 type_id=10
> > > 353 [9] INT signed char size=1 nr_bits=8 encoding=SIGNED
> > > 354 [10] TYPEDEF __u8 type_id=12
> > > 355 [11] INT unsigned char size=1 nr_bits=8 encoding=(none)
> > > 356 [12] CONST (anon) type_id=12
> > > 357 [13] TYPEDEF __s16 type_id=15
> > > 358 [14] INT short int size=2 nr_bits=16 encoding=SIGNED
> > > 359 [15] TYPEDEF __u16 type_id=17
> > > 360 [16] INT short unsigned int size=2 nr_bits=16 encoding=(none)
> > > 361 [17] TYPEDEF __s32 type_id=19
> > > 362 [18] INT int size=4 nr_bits=32 encoding=SIGNED
> > > 363 [19] CONST (anon) type_id=19
> > > 364 [20] TYPEDEF __u32 type_id=7
> > > 365 [21] TYPEDEF __s64 type_id=23
> > >
> > > lines 342-362 of without_IBT
> > >
> > > 342 Found 341 per-CPU variables!
> > > 343 Found 61462 functions!
> > > 344 File .tmp_vmlinux.btf:
> > > 345 [1] FUNC_PROTO (anon) return=0 args=(void)
> > > 346 [2] FUNC verify_cpu type_id=1
> > > 347 [3] FUNC_PROTO (anon) return=0 args=(void)
> > > 348 [4] FUNC sev_verify_cbit type_id=3
> > > 349 search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
> > > 350 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > 351 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > 352 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > 353 Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > 354 Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> > > 355 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > 356 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > 357 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > 358 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > 359 Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
> > > 360 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > 361 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > 362 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > >
> > > If the full debug files are useful or a target grep or diff is better let me know.
> > >
> > I managed to reproduce this too with IBT enabled; one thing I
> > noticed is with pahole built with an up-to-date libbpf and the
> > changes in https://github.com/acmel/dwarves/tree/next, the problem
> > went away. I didn't have time to root-cause it yet however.
> >
> > Not sure if you're in a position to do this, but if you can,
> > would you mind building pahole from
> >
> > https://github.com/acmel/dwarves/tree/next
> >
> > ...and re-testing to see if that helps? Thanks!
> >
> > Alan
> > > Thanks,
> > >
> I tried with libbpf compiled from master
> https://github.com/libbpf/libbpf.git and pahole compiled from next branch on
> https://github.com/acmel/dwarve with the same result.
> With IBT enabled pahole fails and removing it results in a successful
> kernel.
hi,
in case it slipped, you also need to add new options for pahole:
https://lore.kernel.org/bpf/1675949331-27935-1-git-send-email-alan.maguire@oracle.com/
should be added for version 124 for now
jirka
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-02-10 14:34 ` Jiri Olsa
@ 2023-02-10 15:37 ` Alexandre Ferreira
2023-02-14 6:33 ` Tianyi Liu
0 siblings, 1 reply; 30+ messages in thread
From: Alexandre Ferreira @ 2023-02-10 15:37 UTC (permalink / raw)
To: Jiri Olsa; +Cc: Alan Maguire, Daniel Xu, bpf, Arnaldo Carvalho de Melo
Jiri,
On Fri, Feb 10, 2023 at 8:34 AM Jiri Olsa <olsajiri@gmail.com> wrote:
>
> On Fri, Feb 10, 2023 at 08:02:23AM -0600, Alexandre Peixoto Ferreira wrote:
> > Alam,
> >
> > On 2/9/23 07:07, Alan Maguire wrote:
> > > On 09/02/2023 04:15, Alexandre Peixoto Ferreira wrote:
> > > > Jiri,
> > > >
> > > > On 1/31/23 09:18, Jiri Olsa wrote:
> > > > > On Sat, Jan 28, 2023 at 01:23:25PM -0600, Alexandre Peixoto Ferreira wrote:
> > > > > > Jirka and Daniel,
> > > > > >
> > > > > > On 1/27/23 18:00, Jiri Olsa wrote:
> > > > > > > On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
> > > > > > > > On 1/24/23 00:13, Daniel Xu wrote:
> > > > > > > > > Hi Jiri,
> > > > > > > > >
> > > > > > > > > On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
> > > > > > > > > > On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > I'm getting the following error during build:
> > > > > > > > > > >
> > > > > > > > > > > $ ./tools/testing/selftests/bpf/vmtest.sh -j30
> > > > > > > > > > > [...]
> > > > > > > > > > > BTF .btf.vmlinux.bin.o
> > > > > > > > > > > btf_encoder__encode: btf__dedup failed!
> > > > > > > > > > > Failed to encode BTF
> > > > > > > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > > > > > > NM .tmp_vmlinux.kallsyms1.syms
> > > > > > > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > > > > > > NM .tmp_vmlinux.kallsyms2.syms
> > > > > > > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > > > > > > LD .tmp_vmlinux.kallsyms3
> > > > > > > > > > > NM .tmp_vmlinux.kallsyms3.syms
> > > > > > > > > > > KSYMS .tmp_vmlinux.kallsyms3.S
> > > > > > > > > > > AS .tmp_vmlinux.kallsyms3.S
> > > > > > > > > > > LD vmlinux
> > > > > > > > > > > BTFIDS vmlinux
> > > > > > > > > > > FAILED: load BTF from vmlinux: No such file or directory
> > > > > > > > > > > make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
> > > > > > > > > > > make[1]: *** Deleting file 'vmlinux'
> > > > > > > > > > > make: *** [Makefile:1264: vmlinux] Error 2
> > > > > > > > > > >
> > > > > > > > > > > This happens on both bpf-next/master (84150795a49) and 6.2-rc5
> > > > > > > > > > > (2241ab53cb).
> > > > > > > > > > >
> > > > > > > > > > > I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
> > > > > > > > > > > upstream pahole on master (02d67c5176) and upstream pahole on
> > > > > > > > > > > next (2ca56f4c6f659).
> > > > > > > > > > >
> > > > > > > > > > > Of the above 6 combinations, I think I've tried all of them (maybe
> > > > > > > > > > > missing 1 or 2).
> > > > > > > > > > >
> > > > > > > > > > > Looks like GCC got updated recently on my machine, so perhaps
> > > > > > > > > > > it's related?
> > > > > > > > > > >
> > > > > > > > > > > CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
> > > > > > > > > > >
> > > > > > > > > > > I'll try some debugging, but just wanted to report it first.
> > > > > > > > > > hi,
> > > > > > > > > > I can't reproduce that.. can you reproduce it outside vmtest.sh?
> > > > > > > > > >
> > > > > > > > > > there will be lot of output with patch below, but could contain
> > > > > > > > > > some more error output
> > > > > > > > > Thanks for the hints. Doing a regular build outside of vmtest.sh
> > > > > > > > > seems to work ok. So maybe it's a difference in the build config.
> > > > > > > > >
> > > > > > > > > I'll put a little more time into debugging to see if it goes anywhere.
> > > > > > > > > But I'll have to get back to the regularly scheduled programming
> > > > > > > > > soon.
> > > > > > > > 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
> > > > > > > > in pahole when CONFIG_X86_KERNEL_IBT is set.
> > > > > > > could you plese attach your config and the build error?
> > > > > > > I can't reproduce that
> > > > > > >
> > > > > > > thanks,
> > > > > > > jirka
> > > > > > My working .config is available at https://pastebin.pl/view/bef3765c
> > > > > > change CONFIG_X86_KERNEL_IBT to y to get the error.
> > > > > >
> > > > > > The error is similar to Daniel's and is shown below:
> > > > > >
> > > > > > LD .tmp_vmlinux.btf
> > > > > > BTF .btf.vmlinux.bin.o
> > > > > > btf_encoder__encode: btf__dedup failed!
> > > > > > Failed to encode BTF
> > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > NM .tmp_vmlinux.kallsyms1.syms
> > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > NM .tmp_vmlinux.kallsyms2.syms
> > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > LD .tmp_vmlinux.kallsyms3
> > > > > > NM .tmp_vmlinux.kallsyms3.syms
> > > > > > KSYMS .tmp_vmlinux.kallsyms3.S
> > > > > > AS .tmp_vmlinux.kallsyms3.S
> > > > > > LD vmlinux
> > > > > > BTFIDS vmlinux
> > > > > > FAILED: load BTF from vmlinux: No such file or directory
> > > > > > make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
> > > > > > make[1]: *** Deleting file 'vmlinux'
> > > > > > make: *** [Makefile:1264: vmlinux] Error 2
> > > > > I can't reproduce that.. I tried with gcc versions:
> > > > >
> > > > > gcc (GCC) 13.0.1 20230117 (Red Hat 13.0.1-0)
> > > > > gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
> > > > >
> > > > > I haven't found fedora setup with 12.2.1 20230111 yet
> > > > >
> > > > > I tried alsa with latest pahole master branch
> > > > >
> > > > > were you guys able to get any more verbose output
> > > > > that I suggested earlier?
> > > > >
> > > > > jirka
> > > > I compiled with and without IBT using the -V on pahole (LLVM_OBJCOPY=objcopy pahole -V -J --btf_gen_floats -j .tmp_vmlinux.btf) and the outfiles are a little too big (540MB). The error happens with this CONST type pointing to itself. That does not happen with the IBT option removed.
> > > >
> > > > $ grep -n "CONST (anon) type_id" /tmp/with_IBT | more
> > > > 346:[2] CONST (anon) type_id=2
> > > > 349:[5] CONST (anon) type_id=5
> > > > 351:[7] CONST (anon) type_id=7
> > > > 356:[12] CONST (anon) type_id=12
> > > > 363:[19] CONST (anon) type_id=19
> > > > 373:[29] CONST (anon) type_id=29
> > > > 375:[31] CONST (anon) type_id=31
> > > > 409:[63] CONST (anon) type_id=63
> > > > 444:[89] CONST (anon) type_id=0
> > > > 472:[97] CONST (anon) type_id=97
> > > > 616:[129] CONST (anon) type_id=129
> > > > 652:[131] CONST (anon) type_id=131
> > > > 1319:[234] CONST (anon) type_id=234
> > > > 1372:[246] CONST (anon) type_id=246
> > > > ....
> > > >
> > > > $diff -ru with_IBT without_IBT
> > > > --- with_IBT 2023-01-31 09:39:24.915912735 -0600
> > > > +++ without_IBT 2023-01-31 09:46:23.456005278 -0600
> > > > @@ -340,346 +340,14800 @@
> > > > Found per-CPU symbol 'cpu_tlbstate_shared' at address 0x2c040
> > > > Found per-CPU symbol 'mce_poll_banks' at address 0x1ad20
> > > > Found 341 per-CPU variables!
> > > > -Found 61470 functions!
> > > > +Found 61462 functions!
> > > > +File .tmp_vmlinux.btf:
> > > > +[1] FUNC_PROTO (anon) return=0 args=(void)
> > > > +[2] FUNC verify_cpu type_id=1
> > > > +[3] FUNC_PROTO (anon) return=0 args=(void)
> > > > +[4] FUNC sev_verify_cbit type_id=3
> > > > +search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
> > > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > > +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> > > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > > +Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
> > > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > > +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> > > > +Found per-CPU symbol 'last_nmi_rip' at address 0x1a018
> > > > +Found per-CPU symbol 'nmi_stats' at address 0x1a030
> > > > +Found per-CPU symbol 'swallow_nmi' at address 0x1a020
> > > > +Found per-CPU symbol 'nmi_state' at address 0x1a010
> > > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > > +Found per-CPU symbol 'nmi_cr2' at address 0x1a008
> > > > +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > > +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> > > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > > +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > > +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > ...
> > > >
> > > > And the lines 342-365 of the with_IBT result:
> > > > 342 Found 341 per-CPU variables!
> > > > 343 Found 61470 functions!
> > > > 344 File .tmp_vmlinux.btf:
> > > > 345 [1] INT long unsigned int size=8 nr_bits=64 encoding=(none)
> > > > 346 [2] CONST (anon) type_id=2
> > > > 347 [3] PTR (anon) type_id=6
> > > > 348 [4] INT char size=1 nr_bits=8 encoding=(none)
> > > > 349 [5] CONST (anon) type_id=5
> > > > 350 [6] INT unsigned int size=4 nr_bits=32 encoding=(none)
> > > > 351 [7] CONST (anon) type_id=7
> > > > 352 [8] TYPEDEF __s8 type_id=10
> > > > 353 [9] INT signed char size=1 nr_bits=8 encoding=SIGNED
> > > > 354 [10] TYPEDEF __u8 type_id=12
> > > > 355 [11] INT unsigned char size=1 nr_bits=8 encoding=(none)
> > > > 356 [12] CONST (anon) type_id=12
> > > > 357 [13] TYPEDEF __s16 type_id=15
> > > > 358 [14] INT short int size=2 nr_bits=16 encoding=SIGNED
> > > > 359 [15] TYPEDEF __u16 type_id=17
> > > > 360 [16] INT short unsigned int size=2 nr_bits=16 encoding=(none)
> > > > 361 [17] TYPEDEF __s32 type_id=19
> > > > 362 [18] INT int size=4 nr_bits=32 encoding=SIGNED
> > > > 363 [19] CONST (anon) type_id=19
> > > > 364 [20] TYPEDEF __u32 type_id=7
> > > > 365 [21] TYPEDEF __s64 type_id=23
> > > >
> > > > lines 342-362 of without_IBT
> > > >
> > > > 342 Found 341 per-CPU variables!
> > > > 343 Found 61462 functions!
> > > > 344 File .tmp_vmlinux.btf:
> > > > 345 [1] FUNC_PROTO (anon) return=0 args=(void)
> > > > 346 [2] FUNC verify_cpu type_id=1
> > > > 347 [3] FUNC_PROTO (anon) return=0 args=(void)
> > > > 348 [4] FUNC sev_verify_cbit type_id=3
> > > > 349 search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
> > > > 350 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > 351 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > > 352 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > > 353 Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
> > > > 354 Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
> > > > 355 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > 356 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > 357 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > > 358 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
> > > > 359 Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
> > > > 360 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > 361 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
> > > > 362 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
> > > >
> > > > If the full debug files are useful or a target grep or diff is better let me know.
> > > >
> > > I managed to reproduce this too with IBT enabled; one thing I
> > > noticed is with pahole built with an up-to-date libbpf and the
> > > changes in https://github.com/acmel/dwarves/tree/next, the problem
> > > went away. I didn't have time to root-cause it yet however.
> > >
> > > Not sure if you're in a position to do this, but if you can,
> > > would you mind building pahole from
> > >
> > > https://github.com/acmel/dwarves/tree/next
> > >
> > > ...and re-testing to see if that helps? Thanks!
> > >
> > > Alan
> > > > Thanks,
> > > >
> > I tried with libbpf compiled from master
> > https://github.com/libbpf/libbpf.git and pahole compiled from next branch on
> > https://github.com/acmel/dwarve with the same result.
> > With IBT enabled pahole fails and removing it results in a successful
> > kernel.
>
> hi,
> in case it slipped, you also need to add new options for pahole:
> https://lore.kernel.org/bpf/1675949331-27935-1-git-send-email-alan.maguire@oracle.com/
>
> should be added for version 124 for now
>
> jirka
Added the patch to include options on pahole but same problem.
$ pahole --version
v1.25
$ ls -l /usr/lib64/libbpf.so.1.2.0
-rwxr-xr-x 1 root root 422088 Feb 9 13:23 /usr/lib64/libbpf.so.1.2.0
UPD include/generated/utsversion.h
CC init/version-timestamp.o
LD .tmp_vmlinux.btf
BTF .btf.vmlinux.bin.o
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,
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Kernel build fail with 'btf_encoder__encode: btf__dedup failed!'
2023-02-10 15:37 ` Alexandre Ferreira
@ 2023-02-14 6:33 ` Tianyi Liu
2023-04-11 17:00 ` [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes Josh Poimboeuf
0 siblings, 1 reply; 30+ messages in thread
From: Tianyi Liu @ 2023-02-14 6:33 UTC (permalink / raw)
To: alexandref75, olsajiri; +Cc: acme, alan.maguire, bpf, dxu, yhs, Tianyi Liu
Hi Alex and Jiri,
On 2023/2/10 23:37, Alexandre Ferreira wrote:
> Jiri,
>
> On Fri, Feb 10, 2023 at 8:34 AM Jiri Olsa <olsajiri@gmail.com> wrote:
>> On Fri, Feb 10, 2023 at 08:02:23AM -0600, Alexandre Peixoto Ferreira wrote:
>>> Alam,
>>>
>>> On 2/9/23 07:07, Alan Maguire wrote:
>>>> On 09/02/2023 04:15, Alexandre Peixoto Ferreira wrote:
>>>>> Jiri,
>>>>>
>>>>> On 1/31/23 09:18, Jiri Olsa wrote:
>>>>>> On Sat, Jan 28, 2023 at 01:23:25PM -0600, Alexandre Peixoto Ferreira wrote:
>>>>>>> Jirka and Daniel,
>>>>>>>
>>>>>>> On 1/27/23 18:00, Jiri Olsa wrote:
>>>>>>>> On Fri, Jan 27, 2023 at 04:28:54PM -0600, Alexandre Peixoto Ferreira wrote:
>>>>>>>>> On 1/24/23 00:13, Daniel Xu wrote:
>>>>>>>>>> Hi Jiri,
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 23, 2023, at 1:06 AM, Jiri Olsa wrote:
>>>>>>>>>>> On Sun, Jan 22, 2023 at 10:48:44AM -0700, Daniel Xu wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm getting the following error during build:
>>>>>>>>>>>>
>>>>>>>>>>>> $ ./tools/testing/selftests/bpf/vmtest.sh -j30
>>>>>>>>>>>> [...]
>>>>>>>>>>>> BTF .btf.vmlinux.bin.o
>>>>>>>>>>>> btf_encoder__encode: btf__dedup failed!
>>>>>>>>>>>> Failed to encode BTF
>>>>>>>>>>>> LD .tmp_vmlinux.kallsyms1
>>>>>>>>>>>> NM .tmp_vmlinux.kallsyms1.syms
>>>>>>>>>>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>>>>>>>>>>> AS .tmp_vmlinux.kallsyms1.S
>>>>>>>>>>>> LD .tmp_vmlinux.kallsyms2
>>>>>>>>>>>> NM .tmp_vmlinux.kallsyms2.syms
>>>>>>>>>>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>>>>>>>>>>> AS .tmp_vmlinux.kallsyms2.S
>>>>>>>>>>>> LD .tmp_vmlinux.kallsyms3
>>>>>>>>>>>> NM .tmp_vmlinux.kallsyms3.syms
>>>>>>>>>>>> KSYMS .tmp_vmlinux.kallsyms3.S
>>>>>>>>>>>> AS .tmp_vmlinux.kallsyms3.S
>>>>>>>>>>>> LD vmlinux
>>>>>>>>>>>> BTFIDS vmlinux
>>>>>>>>>>>> FAILED: load BTF from vmlinux: No such file or directory
>>>>>>>>>>>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>>>>>>>>>>> make[1]: *** Deleting file 'vmlinux'
>>>>>>>>>>>> make: *** [Makefile:1264: vmlinux] Error 2
>>>>>>>>>>>>
>>>>>>>>>>>> This happens on both bpf-next/master (84150795a49) and 6.2-rc5
>>>>>>>>>>>> (2241ab53cb).
>>>>>>>>>>>>
>>>>>>>>>>>> I've also tried arch linux pahole 1:1.24+r29+g02d67c5-1 as well as
>>>>>>>>>>>> upstream pahole on master (02d67c5176) and upstream pahole on
>>>>>>>>>>>> next (2ca56f4c6f659).
>>>>>>>>>>>>
>>>>>>>>>>>> Of the above 6 combinations, I think I've tried all of them (maybe
>>>>>>>>>>>> missing 1 or 2).
>>>>>>>>>>>>
>>>>>>>>>>>> Looks like GCC got updated recently on my machine, so perhaps
>>>>>>>>>>>> it's related?
>>>>>>>>>>>>
>>>>>>>>>>>> CONFIG_CC_VERSION_TEXT="gcc (GCC) 12.2.1 20230111"
>>>>>>>>>>>>
>>>>>>>>>>>> I'll try some debugging, but just wanted to report it first.
>>>>>>>>>>> hi,
>>>>>>>>>>> I can't reproduce that.. can you reproduce it outside vmtest.sh?
>>>>>>>>>>>
>>>>>>>>>>> there will be lot of output with patch below, but could contain
>>>>>>>>>>> some more error output
>>>>>>>>>> Thanks for the hints. Doing a regular build outside of vmtest.sh
>>>>>>>>>> seems to work ok. So maybe it's a difference in the build config.
>>>>>>>>>>
>>>>>>>>>> I'll put a little more time into debugging to see if it goes anywhere.
>>>>>>>>>> But I'll have to get back to the regularly scheduled programming
>>>>>>>>>> soon.
>>>>>>>>> 6.2-rc5 compiles correctly when CONFIG_X86_KERNEL_IBT is commented but fails
>>>>>>>>> in pahole when CONFIG_X86_KERNEL_IBT is set.
>>>>>>>> could you plese attach your config and the build error?
>>>>>>>> I can't reproduce that
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> jirka
>>>>>>> My working .config is available at https://pastebin.pl/view/bef3765c
>>>>>>> change CONFIG_X86_KERNEL_IBT to y to get the error.
>>>>>>>
>>>>>>> The error is similar to Daniel's and is shown below:
>>>>>>>
>>>>>>> LD .tmp_vmlinux.btf
>>>>>>> BTF .btf.vmlinux.bin.o
>>>>>>> btf_encoder__encode: btf__dedup failed!
>>>>>>> Failed to encode BTF
>>>>>>> LD .tmp_vmlinux.kallsyms1
>>>>>>> NM .tmp_vmlinux.kallsyms1.syms
>>>>>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>>>>>> AS .tmp_vmlinux.kallsyms1.S
>>>>>>> LD .tmp_vmlinux.kallsyms2
>>>>>>> NM .tmp_vmlinux.kallsyms2.syms
>>>>>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>>>>>> AS .tmp_vmlinux.kallsyms2.S
>>>>>>> LD .tmp_vmlinux.kallsyms3
>>>>>>> NM .tmp_vmlinux.kallsyms3.syms
>>>>>>> KSYMS .tmp_vmlinux.kallsyms3.S
>>>>>>> AS .tmp_vmlinux.kallsyms3.S
>>>>>>> LD vmlinux
>>>>>>> BTFIDS vmlinux
>>>>>>> FAILED: load BTF from vmlinux: No such file or directory
>>>>>>> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
>>>>>>> make[1]: *** Deleting file 'vmlinux'
>>>>>>> make: *** [Makefile:1264: vmlinux] Error 2
>>>>>> I can't reproduce that.. I tried with gcc versions:
>>>>>>
>>>>>> gcc (GCC) 13.0.1 20230117 (Red Hat 13.0.1-0)
>>>>>> gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
>>>>>>
>>>>>> I haven't found fedora setup with 12.2.1 20230111 yet
>>>>>>
>>>>>> I tried alsa with latest pahole master branch
>>>>>>
>>>>>> were you guys able to get any more verbose output
>>>>>> that I suggested earlier?
>>>>>>
>>>>>> jirka
>>>>> I compiled with and without IBT using the -V on pahole (LLVM_OBJCOPY=objcopy pahole -V -J --btf_gen_floats -j .tmp_vmlinux.btf) and the outfiles are a little too big (540MB). The error happens with this CONST type pointing to itself. That does not happen with the IBT option removed.
>>>>>
>>>>> $ grep -n "CONST (anon) type_id" /tmp/with_IBT | more
>>>>> 346:[2] CONST (anon) type_id=2
>>>>> 349:[5] CONST (anon) type_id=5
>>>>> 351:[7] CONST (anon) type_id=7
>>>>> 356:[12] CONST (anon) type_id=12
>>>>> 363:[19] CONST (anon) type_id=19
>>>>> 373:[29] CONST (anon) type_id=29
>>>>> 375:[31] CONST (anon) type_id=31
>>>>> 409:[63] CONST (anon) type_id=63
>>>>> 444:[89] CONST (anon) type_id=0
>>>>> 472:[97] CONST (anon) type_id=97
>>>>> 616:[129] CONST (anon) type_id=129
>>>>> 652:[131] CONST (anon) type_id=131
>>>>> 1319:[234] CONST (anon) type_id=234
>>>>> 1372:[246] CONST (anon) type_id=246
>>>>> ....
>>>>>
>>>>> $diff -ru with_IBT without_IBT
>>>>> --- with_IBT 2023-01-31 09:39:24.915912735 -0600
>>>>> +++ without_IBT 2023-01-31 09:46:23.456005278 -0600
>>>>> @@ -340,346 +340,14800 @@
>>>>> Found per-CPU symbol 'cpu_tlbstate_shared' at address 0x2c040
>>>>> Found per-CPU symbol 'mce_poll_banks' at address 0x1ad20
>>>>> Found 341 per-CPU variables!
>>>>> -Found 61470 functions!
>>>>> +Found 61462 functions!
>>>>> +File .tmp_vmlinux.btf:
>>>>> +[1] FUNC_PROTO (anon) return=0 args=(void)
>>>>> +[2] FUNC verify_cpu type_id=1
>>>>> +[3] FUNC_PROTO (anon) return=0 args=(void)
>>>>> +[4] FUNC sev_verify_cbit type_id=3
>>>>> +search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
>>>>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>>>>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>>>>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>>>>> +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
>>>>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>>>>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>>>>> +Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
>>>>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>>>>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>>>>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>>>>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>>>>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>>>>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>>>>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> +Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>>>>> +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
>>>>> +Found per-CPU symbol 'last_nmi_rip' at address 0x1a018
>>>>> +Found per-CPU symbol 'nmi_stats' at address 0x1a030
>>>>> +Found per-CPU symbol 'swallow_nmi' at address 0x1a020
>>>>> +Found per-CPU symbol 'nmi_state' at address 0x1a010
>>>>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>>>>> +Found per-CPU symbol 'nmi_cr2' at address 0x1a008
>>>>> +Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>>>>> +Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
>>>>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>>>>> +Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>>>>> +Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> ...
>>>>>
>>>>> And the lines 342-365 of the with_IBT result:
>>>>> 342 Found 341 per-CPU variables!
>>>>> 343 Found 61470 functions!
>>>>> 344 File .tmp_vmlinux.btf:
>>>>> 345 [1] INT long unsigned int size=8 nr_bits=64 encoding=(none)
>>>>> 346 [2] CONST (anon) type_id=2
>>>>> 347 [3] PTR (anon) type_id=6
>>>>> 348 [4] INT char size=1 nr_bits=8 encoding=(none)
>>>>> 349 [5] CONST (anon) type_id=5
>>>>> 350 [6] INT unsigned int size=4 nr_bits=32 encoding=(none)
>>>>> 351 [7] CONST (anon) type_id=7
>>>>> 352 [8] TYPEDEF __s8 type_id=10
>>>>> 353 [9] INT signed char size=1 nr_bits=8 encoding=SIGNED
>>>>> 354 [10] TYPEDEF __u8 type_id=12
>>>>> 355 [11] INT unsigned char size=1 nr_bits=8 encoding=(none)
>>>>> 356 [12] CONST (anon) type_id=12
>>>>> 357 [13] TYPEDEF __s16 type_id=15
>>>>> 358 [14] INT short int size=2 nr_bits=16 encoding=SIGNED
>>>>> 359 [15] TYPEDEF __u16 type_id=17
>>>>> 360 [16] INT short unsigned int size=2 nr_bits=16 encoding=(none)
>>>>> 361 [17] TYPEDEF __s32 type_id=19
>>>>> 362 [18] INT int size=4 nr_bits=32 encoding=SIGNED
>>>>> 363 [19] CONST (anon) type_id=19
>>>>> 364 [20] TYPEDEF __u32 type_id=7
>>>>> 365 [21] TYPEDEF __s64 type_id=23
>>>>>
>>>>> lines 342-362 of without_IBT
>>>>>
>>>>> 342 Found 341 per-CPU variables!
>>>>> 343 Found 61462 functions!
>>>>> 344 File .tmp_vmlinux.btf:
>>>>> 345 [1] FUNC_PROTO (anon) return=0 args=(void)
>>>>> 346 [2] FUNC verify_cpu type_id=1
>>>>> 347 [3] FUNC_PROTO (anon) return=0 args=(void)
>>>>> 348 [4] FUNC sev_verify_cbit type_id=3
>>>>> 349 search cu 'arch/x86/kernel/head_64.S' for percpu global variables.
>>>>> 350 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> 351 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>>>>> 352 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>>>>> 353 Found per-CPU symbol 'cpu_kick_mask' at address 0x19f78
>>>>> 354 Found per-CPU symbol 'cpu_tsc_khz' at address 0x19f88
>>>>> 355 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> 356 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> 357 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>>>>> 358 Found per-CPU symbol 'perf_nmi_tstamp' at address 0x19f70
>>>>> 359 Found per-CPU symbol 'current_tsc_ratio' at address 0x19fa0
>>>>> 360 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> 361 Found per-CPU symbol 'cpu_loops_per_jiffy' at address 0x18a08
>>>>> 362 Found per-CPU symbol 'kvm_running_vcpu' at address 0x19f80
>>>>>
>>>>> If the full debug files are useful or a target grep or diff is better let me know.
>>>>>
>>>> I managed to reproduce this too with IBT enabled; one thing I
>>>> noticed is with pahole built with an up-to-date libbpf and the
>>>> changes in https://github.com/acmel/dwarves/tree/next, the problem
>>>> went away. I didn't have time to root-cause it yet however.
>>>>
>>>> Not sure if you're in a position to do this, but if you can,
>>>> would you mind building pahole from
>>>>
>>>> https://github.com/acmel/dwarves/tree/next
>>>>
>>>> ...and re-testing to see if that helps? Thanks!
>>>>
>>>> Alan
>>>>> Thanks,
>>>>>
>>> I tried with libbpf compiled from master
>>> https://github.com/libbpf/libbpf.git and pahole compiled from next branch on
>>> https://github.com/acmel/dwarve with the same result.
>>> With IBT enabled pahole fails and removing it results in a successful
>>> kernel.
>> hi,
>> in case it slipped, you also need to add new options for pahole:
>> https://lore.kernel.org/bpf/1675949331-27935-1-git-send-email-alan.maguire@oracle.com/
>>
>> should be added for version 124 for now
>>
>> jirka
>
> Added the patch to include options on pahole but same problem.
> $ pahole --version
> v1.25
> $ ls -l /usr/lib64/libbpf.so.1.2.0
> -rwxr-xr-x 1 root root 422088 Feb 9 13:23 /usr/lib64/libbpf.so.1.2.0
>
> UPD include/generated/utsversion.h
> CC init/version-timestamp.o
> LD .tmp_vmlinux.btf
> BTF .btf.vmlinux.bin.o
> 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.
For example:
$readelf -n linux-6.2-rc7-with-IBT/.tmp_vmlinux.btf
Displaying notes found in: .notes
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 feature used: x86, x87, MMX, XMM, FXSR, XSAVE
x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3
Linux 0x00000004 func
description data: 06 00 00 00
readelf: Warning: note with invalid namesz and/or descsz found at offset 0x50
readelf: Warning: type: 0x78, namesize: 0x100, descsize: 0x756e694c, alignment: 8
$readelf -n linux-6.2-rc7-no-IBT/.tmp_vmlinux.btf
Displaying notes found in: .notes
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 feature used: x86, x87, MMX, XMM, FXSR, XSAVE
x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 073b8e5b0373cdc806fac20a9559461be75570a8
readelf: Warning: note with invalid namesz and/or descsz found at offset 0x58
readelf: Warning: type: 0x756e694c, namesize: 0x4, descsize: 0x101, alignment: 8
As shown above, whether IBT is enabled or not, readelf can't read all records
in the .notes section. And gelf_getnote() has the same behaviour.
In dwarf_loader.c:3001, cus__merging_cu() determines whether cu(compile unit)
should be merged by detecting the value of LINUX_ELFNOTE_LTO_INFO. It is from
https://github.com/torvalds/linux/blob/master/include/linux/elfnote-lto.h#L9,
and its value must be 0 or 1. But in the above output from readelf, it reads
"06 00 00 00"(=6), which is impossible. This confirms that the .notes record
has format compatibility problems. There's also something similar at
https://lore.kernel.org/linux-arm-kernel/20210428172847.GC4022@arm.com/
dwarf_loader.c:3001 uses "!= 0" for judgement. So with IBT=y, gelf_getnote()
reads "0x6" and return "true"; while gelf_getnote() crushed before reading the
LINUX_ELFNOTE_LTO_INFO with IBT=n, and returns the right result("false")
coincidently. Since the kernel is not built with CONFIG_LTO, merging compile
units will lead to undefined behaviors.
Specifically, there are tags such as DW_TAG_unspecified_type in the origin cus,
but were filtered out in BTF encders. This causes the small_id(dwarf reader assigned)
is malposed with the offset(which btf encoder uses), and finally leads to the
"btf__dedup failed!" error.
There's an simple fix for pahole. To some extent, this prevents cus__merging_cu()
from being disturbed by alignment errors, but the fundamental solution is to
fix the alignment problem of .notes section.
Signed-off-by: Tianyi Liu <i.pear@outlook.com>
---
dwarf_loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dwarf_loader.c b/dwarf_loader.c
index a77598d..b2e9863 100644
--- a/dwarf_loader.c
+++ b/dwarf_loader.c
@@ -2998,7 +2998,7 @@ static bool cus__merging_cu(Dwarf *dw, Elf *elf)
if (strcmp((char *)data->d_buf + name_off, "Linux") != 0)
continue;
- return *(int *)(data->d_buf + desc_off) != 0;
+ return *(int *)(data->d_buf + desc_off) == 1;
}
}
}
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes
2023-02-14 6:33 ` Tianyi Liu
@ 2023-04-11 17:00 ` Josh Poimboeuf
2023-04-12 7:10 ` Tianyi Liu
0 siblings, 1 reply; 30+ messages in thread
From: Josh Poimboeuf @ 2023-04-11 17:00 UTC (permalink / raw)
To: Tianyi Liu
Cc: alexandref75, olsajiri, acme, alan.maguire, bpf, dxu, yhs,
Peter Zijlstra, linux-kernel, ptalbert, jforbes
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 <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
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes
2023-04-11 17:00 ` [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes Josh Poimboeuf
@ 2023-04-12 7:10 ` Tianyi Liu
2023-04-12 16:30 ` Josh Poimboeuf
0 siblings, 1 reply; 30+ messages in thread
From: Tianyi Liu @ 2023-04-12 7:10 UTC (permalink / raw)
To: jpoimboe
Cc: acme, alan.maguire, alexandref75, bpf, dxu, i.pear, jforbes,
linux-kernel, olsajiri, peterz, ptalbert, yhs
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes
2023-04-12 7:10 ` Tianyi Liu
@ 2023-04-12 16:30 ` Josh Poimboeuf
2023-04-13 2:21 ` Joan Bruguera Micó
2023-04-13 4:54 ` [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes Tianyi Liu
0 siblings, 2 replies; 30+ messages in thread
From: Josh Poimboeuf @ 2023-04-12 16:30 UTC (permalink / raw)
To: Tianyi Liu
Cc: acme, alan.maguire, alexandref75, bpf, dxu, jforbes,
linux-kernel, olsajiri, peterz, ptalbert, yhs
On Wed, Apr 12, 2023 at 03:10:14PM +0800, Tianyi Liu wrote:
> 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
Hm, weird.
> > 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.
So just to confirm, the btf__dedup error is gone for you with the latest
dwarves?
--
Josh
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes
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 4:54 ` [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes Tianyi Liu
1 sibling, 1 reply; 30+ messages in thread
From: Joan Bruguera Micó @ 2023-04-13 2:21 UTC (permalink / raw)
To: jpoimboe
Cc: i.pear, acme, alan.maguire, alexandref75, bpf, dxu, jforbes,
linux-kernel, olsajiri, peterz, ptalbert, yhs
I have done some tests with Arch Linux which is also affected by this issue:
Base scenario: Running Arch Linux updated as of 2023-04-13.
Building the linux-mainline 6.3rc6-1 from AUR
(https://aur.archlinux.org/packages/linux-mainline)
with CONFIG_X86_KERNEL_IBT changed to 'y'
Result: Build fails with the "btf__dedup failed!" error
Test 1: Update dwarves (=pahole package on Arch Linux) from the current version
(1:1.24+r29+g02d67c5-1) to the staging version (1:1.25-1).
Result: The build works correctly.
However, the notes section is still not parsed correctly, as confirmed
by `readelf -n` or adding a printf near the code on `cus__merging_cu`
(on `dwarf_loader.c`) pointed to by Tianyi.
A bisect shows the commit that fixes the build is
a9498899109d3be14f17abbc322a8f55a1067bee
"dwarf_loader: Fix for BTF id drift caused by adding unspecified types"
I don't know why though.
Test 2: Applying Josh's patch to force-align the ELF notes section to 4 bytes
(clarification: using the base pahole version again here)
Result: The build works correctly.
I can read the notes correctly using `readelf -n` as well,
and they are aligned to 4 bytes instead of 8.
Test 3: Similar to Josh's patch, but instead of force-aligning the sections,
I added `.note.gnu.property` to the `/DISCARD/` list in the line above.
Result: The build works correctly.
I can read the notes correctly using `readelf -n` as well
(of course, the GNU notes which made the alignment be 8 bytes are gone;
I don't know if this has any negative effect).
So, in summary, either upgrading dwarves/pahole from 1.24 to (not yet fully
released?) 1.25, or applying Josh's patch fixes the issue for me.
Despite the new dwarves/pahole version fixing the build, Josh's patch or
something else to fix the notes alignment is needed.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes
2023-04-12 16:30 ` Josh Poimboeuf
2023-04-13 2:21 ` Joan Bruguera Micó
@ 2023-04-13 4:54 ` Tianyi Liu
2023-04-16 18:52 ` Joan Bruguera Micó
1 sibling, 1 reply; 30+ messages in thread
From: Tianyi Liu @ 2023-04-13 4:54 UTC (permalink / raw)
To: jpoimboe
Cc: acme, alan.maguire, alexandref75, bpf, dxu, i.pear, jforbes,
linux-kernel, olsajiri, peterz, ptalbert, yhs, joanbrugueram
On Wed, Apr 12, 2023 at 16:30PM UTC, Josh Poimboeuf wrote:
> On Wed, Apr 12, 2023 at 03:10:14PM +0800, Tianyi Liu wrote:
> > 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
>
> Hm, weird.
I have consulted some materials and found that using ALIGN() in linker
scripts can only "increase" alignment, not decrease it.
Perhaps could you try modifying your patch to use ALIGN(2) and SUBALIGN(2)
and see if the .notes section in the output file is aligned to 2?
In my tests, this had no effect.
[1] https://sourceware.org/binutils/docs/ld/Forced-Output-Alignment.html
>
> > > 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.
>
> So just to confirm, the btf__dedup error is gone for you with the latest
> dwarves?
Yes, this issue was fixed after a9498899109d3be14f17abbc322a8f55a1067bee
("dwarf_loader: Fix for BTF id drift caused by adding unspecified types"),
which will be included in version 1.25.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes
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
0 siblings, 1 reply; 30+ messages in thread
From: Tianyi Liu @ 2023-04-13 9:23 UTC (permalink / raw)
To: joanbrugueram
Cc: acme, alan.maguire, alexandref75, bpf, dxu, i.pear, jforbes,
jpoimboe, linux-kernel, olsajiri, peterz, ptalbert, yhs
On Thu, Apr 13, 2023 at 02:21:49 +0000, Joan Bruguera Micó wrote:
> I have done some tests with Arch Linux which is also affected by this issue:
>
> Base scenario: Running Arch Linux updated as of 2023-04-13.
> Building the linux-mainline 6.3rc6-1 from AUR
> (https://aur.archlinux.org/packages/linux-mainline)
> with CONFIG_X86_KERNEL_IBT changed to 'y'
> Result: Build fails with the "btf__dedup failed!" error
I use MANJARO with kernel version 6.2.10-1. We should be using the same kernel.
> Test 1: Update dwarves (=pahole package on Arch Linux) from the current version
> (1:1.24+r29+g02d67c5-1) to the staging version (1:1.25-1).
> Result: The build works correctly.
>
> However, the notes section is still not parsed correctly, as confirmed
> by `readelf -n` or adding a printf near the code on `cus__merging_cu`
> (on `dwarf_loader.c`) pointed to by Tianyi.
>
> A bisect shows the commit that fixes the build is
> a9498899109d3be14f17abbc322a8f55a1067bee
> "dwarf_loader: Fix for BTF id drift caused by adding unspecified types"
> I don't know why though.
Pahole reads .notes to look for LINUX_ELFNOTE_BUILD_LTO. When LTO is
enabled, pahole needs to call cus__merge_and_process_cu to merge compile
units, at which point there should only be one unspecified type (used to
represent some compilation information) in the global context.
However, when the kernel is compiled without LTO, if pahole calls
cus__merge_and_process_cu due to alignment issues with notes, multiple
unspecified types may appear after merging the cus, and older versions of
pahole only support up to one. This is why pahole 1.24 crashes, while
newer versions support multiple. However, the latest version of pahole
still does not solve the problem of incorrect LTO recognition, so
compiling the kernel may be slower than normal.
If the only objective is to fix the bug of incorrect LTO recognition,
perhaps this naive patch[1] could be sufficient.
[1]: https://lore.kernel.org/bpf/SY4P282MB1084A0E31D4228DF89FC42639DA29@SY4P282MB1084.AUSP282.PROD.OUTLOOK.COM/
> Test 2: Applying Josh's patch to force-align the ELF notes section to 4 bytes
> (clarification: using the base pahole version again here)
> Result: The build works correctly.
> I can read the notes correctly using `readelf -n` as well,
> and they are aligned to 4 bytes instead of 8.
I'm still currently unable to reproduce this fix, but it may just be an
issue with my environment.
> Test 3: Similar to Josh's patch, but instead of force-aligning the sections,
> I added `.note.gnu.property` to the `/DISCARD/` list in the line above.
> Result: The build works correctly.
> I can read the notes correctly using `readelf -n` as well
> (of course, the GNU notes which made the alignment be 8 bytes are gone;
> I don't know if this has any negative effect).
I think discarding .note.gnu.property will not have side effects. For some
reason, this note does not exist in my final vmlinux. I also did not find
any usage of this property in the later steps of compiling the kernel.
> So, in summary, either upgrading dwarves/pahole from 1.24 to (not yet fully
> released?) 1.25, or applying Josh's patch fixes the issue for me.
> Despite the new dwarves/pahole version fixing the build, Josh's patch or
> something else to fix the notes alignment is needed.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH] vmlinux.lds.h: Discard .note.gnu.property section
2023-04-13 9:23 ` Tianyi Liu
@ 2023-04-13 18:59 ` Josh Poimboeuf
2023-04-16 19:02 ` Joan Bruguera Micó
0 siblings, 1 reply; 30+ messages in thread
From: Josh Poimboeuf @ 2023-04-13 18:59 UTC (permalink / raw)
To: Tianyi Liu
Cc: joanbrugueram, acme, alan.maguire, alexandref75, bpf, dxu,
jforbes, linux-kernel, olsajiri, peterz, ptalbert, yhs
On Thu, Apr 13, 2023 at 05:23:08PM +0800, Tianyi Liu wrote:
> > Test 1: Update dwarves (=pahole package on Arch Linux) from the current version
> > (1:1.24+r29+g02d67c5-1) to the staging version (1:1.25-1).
> > Result: The build works correctly.
> >
> > However, the notes section is still not parsed correctly, as confirmed
> > by `readelf -n` or adding a printf near the code on `cus__merging_cu`
> > (on `dwarf_loader.c`) pointed to by Tianyi.
> >
> > A bisect shows the commit that fixes the build is
> > a9498899109d3be14f17abbc322a8f55a1067bee
> > "dwarf_loader: Fix for BTF id drift caused by adding unspecified types"
> > I don't know why though.
>
> Pahole reads .notes to look for LINUX_ELFNOTE_BUILD_LTO. When LTO is
> enabled, pahole needs to call cus__merge_and_process_cu to merge compile
> units, at which point there should only be one unspecified type (used to
> represent some compilation information) in the global context.
>
> However, when the kernel is compiled without LTO, if pahole calls
> cus__merge_and_process_cu due to alignment issues with notes, multiple
> unspecified types may appear after merging the cus, and older versions of
> pahole only support up to one. This is why pahole 1.24 crashes, while
> newer versions support multiple. However, the latest version of pahole
> still does not solve the problem of incorrect LTO recognition, so
> compiling the kernel may be slower than normal.
Thanks for the explanation. So pahole is still mis-reading the LTO
note, it just doesn't crash now.
> If the only objective is to fix the bug of incorrect LTO recognition,
> perhaps this naive patch[1] could be sufficient.
>
> [1]: https://lore.kernel.org/bpf/SY4P282MB1084A0E31D4228DF89FC42639DA29@SY4P282MB1084.AUSP282.PROD.OUTLOOK.COM/
I think we still need to fix the underlying issue (corrupt .notes
section).
> > Test 2: Applying Josh's patch to force-align the ELF notes section to 4 bytes
> > (clarification: using the base pahole version again here)
> > Result: The build works correctly.
> > I can read the notes correctly using `readelf -n` as well,
> > and they are aligned to 4 bytes instead of 8.
>
> I'm still currently unable to reproduce this fix, but it may just be an
> issue with my environment.
>
> > Test 3: Similar to Josh's patch, but instead of force-aligning the sections,
> > I added `.note.gnu.property` to the `/DISCARD/` list in the line above.
> > Result: The build works correctly.
> > I can read the notes correctly using `readelf -n` as well
> > (of course, the GNU notes which made the alignment be 8 bytes are gone;
> > I don't know if this has any negative effect).
>
> I think discarding .note.gnu.property will not have side effects. For some
> reason, this note does not exist in my final vmlinux. I also did not find
> any usage of this property in the later steps of compiling the kernel.
It looks like CONFIG_DEBUG_INFO_BTF is already (inadvertently) stripping
it from vmlinux due to how GNU properties are merged by the linker (see
"How GNU properties are merged" in the ld man page).
The btf data is extracted from vmlinux.o with "objcopy
--only-section=.BTF" into .btf.vmlinux.bin.o. That file doesn't have
.note.gnu.property, so when it gets modified and linked back into the
main object, the linker strips it.
GNU properties are important for user space but they don't seem to have
a purpose for vmlinux. So yeah, let's just discard .note.gnu.property.
---8<---
From: Josh Poimboeuf <jpoimboe@kernel.org>
Subject: [PATCH] vmlinux.lds.h: Discard .note.gnu.property section
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
This latter error was caused by pahole crashing when it encountered the
corrupt .notes section. This crash has been fixed in dwarves version
1.25. As Tianyi Liu describes:
"Pahole reads .notes to look for LINUX_ELFNOTE_BUILD_LTO. When LTO is
enabled, pahole needs to call cus__merge_and_process_cu to merge
compile units, at which point there should only be one unspecified
type (used to represent some compilation information) in the global
context.
However, when the kernel is compiled without LTO, if pahole calls
cus__merge_and_process_cu due to alignment issues with notes,
multiple unspecified types may appear after merging the cus, and
older versions of pahole only support up to one. This is why pahole
1.24 crashes, while newer versions support multiple. However, the
latest version of pahole still does not solve the problem of
incorrect LTO recognition, so compiling the kernel may be slower
than normal."
Even with the newer pahole, the note section misaligment issue still
exists and pahole is misinterpreting the LTO note. Fix it by discarding
the .note.gnu.property section. While GNU properties are important for
user space (and VDSO), they don't seem to have any use for vmlinux.
(In fact, they're already getting (inadvertently) stripped from vmlinux
when CONFIG_DEBUG_INFO_BTF is enabled. The BTF data is extracted from
vmlinux.o with "objcopy --only-section=.BTF" into .btf.vmlinux.bin.o.
That file doesn't have .note.gnu.property, so when it gets modified and
linked back into the main object, the linker automatically strips it
(see "How GNU properties are merged" in the ld man page).)
Reported-by: Daniel Xu <dxu@dxuuu.xyz>
Link: https://lkml.kernel.org/lkml/57830c30-cd77-40cf-9cd1-3bb608aa602e@app.fastmail.com
Debugged-by: Tianyi Liu <i.pear@outlook.com>
Suggested-by: Joan Bruguera Micó <joanbrugueram@gmail.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
include/asm-generic/vmlinux.lds.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index d1f57e4868ed..1770b7d87a80 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -894,6 +894,7 @@
*/
#define NOTES \
/DISCARD/ : { *(.note.GNU-stack) } \
+ /DISCARD/ : { *(.note.gnu.property) } \
.notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
BOUNDED_SECTION_BY(.note.*, _notes) \
} NOTES_HEADERS \
--
2.39.2
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes
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ó
0 siblings, 1 reply; 30+ messages in thread
From: Joan Bruguera Micó @ 2023-04-16 18:52 UTC (permalink / raw)
To: jpoimboe, i.pear
Cc: acme, alan.maguire, alexandref75, bpf, dxu, jforbes,
linux-kernel, olsajiri, peterz, ptalbert, yhs
On Thu, Apr 13, 2023 at 12:54:19PM +0800, Tianyi Liu wrote:
> On Wed, Apr 12, 2023 at 16:30PM UTC, Josh Poimboeuf wrote:
> > On Wed, Apr 12, 2023 at 03:10:14PM +0800, Tianyi Liu wrote:
> > > 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
> >
> > Hm, weird.
>
> I have consulted some materials and found that using ALIGN() in linker
> scripts can only "increase" alignment, not decrease it.
>
> Perhaps could you try modifying your patch to use ALIGN(2) and SUBALIGN(2)
> and see if the .notes section in the output file is aligned to 2?
> In my tests, this had no effect.
>
> [1] https://sourceware.org/binutils/docs/ld/Forced-Output-Alignment.html
Not sure about the ld documentation (it may just be ambiguous wording)
but while doing some tests, I have found that Josh's ALIGN/SUBALIGN(4)
patch only works for certain kernel configs and fails for others.
This likely explains why Josh's patch worked for me but not for Tianyi.
I haven't investigated why or when it works though, but here's a config
where Josh's ALIGN(4) patch works and or where it doesn't (for me):
https://zealcharm.com/20230416-btf-dedup-bug-sample-configs/align-4-working
https://zealcharm.com/20230416-btf-dedup-bug-sample-configs/align-4-not-working
OTOH the new patch to discard .note.gnu.property works in both cases.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH] vmlinux.lds.h: Discard .note.gnu.property section
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
0 siblings, 1 reply; 30+ messages in thread
From: Joan Bruguera Micó @ 2023-04-16 19:02 UTC (permalink / raw)
To: jpoimboe
Cc: i.pear, acme, alan.maguire, alexandref75, bpf, dxu, jforbes,
linux-kernel, olsajiri, peterz, ptalbert, yhs
Two small nitpicks:
> Link: https://lkml.kernel.org/lkml/57830c30-cd77-40cf-9cd1-3bb608aa602e@app.fastmail.com
This link is "semi-broken", it should go to /bpf/ instead of /lkml/.
> /DISCARD/ : { *(.note.GNU-stack) } \
> + /DISCARD/ : { *(.note.gnu.property) } \
Both discards can go in the same DISCARD block.
(just style; it's how it's most often done in other linker scripts)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] vmlinux.lds.h: Discard .note.gnu.property section
2023-04-16 19:02 ` Joan Bruguera Micó
@ 2023-04-18 21:47 ` Josh Poimboeuf
2023-04-18 21:49 ` [PATCH v2] " Josh Poimboeuf
0 siblings, 1 reply; 30+ messages in thread
From: Josh Poimboeuf @ 2023-04-18 21:47 UTC (permalink / raw)
To: Joan Bruguera Micó
Cc: i.pear, acme, alan.maguire, alexandref75, bpf, dxu, jforbes,
linux-kernel, olsajiri, peterz, ptalbert, yhs
On Sun, Apr 16, 2023 at 07:02:19PM +0000, Joan Bruguera Micó wrote:
> Two small nitpicks:
>
> > Link: https://lkml.kernel.org/lkml/57830c30-cd77-40cf-9cd1-3bb608aa602e@app.fastmail.com
>
> This link is "semi-broken", it should go to /bpf/ instead of /lkml/.
>
> > /DISCARD/ : { *(.note.GNU-stack) } \
> > + /DISCARD/ : { *(.note.gnu.property) } \
>
> Both discards can go in the same DISCARD block.
> (just style; it's how it's most often done in other linker scripts)
Thanks. I also noticed the comment above the change needs an update.
Posting v2 shortly.
--
Josh
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v2] vmlinux.lds.h: Discard .note.gnu.property section
2023-04-18 21:47 ` Josh Poimboeuf
@ 2023-04-18 21:49 ` Josh Poimboeuf
0 siblings, 0 replies; 30+ messages in thread
From: Josh Poimboeuf @ 2023-04-18 21:49 UTC (permalink / raw)
To: Joan Bruguera Micó
Cc: i.pear, acme, alan.maguire, alexandref75, bpf, dxu, jforbes,
linux-kernel, olsajiri, peterz, ptalbert, yhs
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
This latter error was caused by pahole crashing when it encountered the
corrupt .notes section. This crash has been fixed in dwarves version
1.25. As Tianyi Liu describes:
"Pahole reads .notes to look for LINUX_ELFNOTE_BUILD_LTO. When LTO is
enabled, pahole needs to call cus__merge_and_process_cu to merge
compile units, at which point there should only be one unspecified
type (used to represent some compilation information) in the global
context.
However, when the kernel is compiled without LTO, if pahole calls
cus__merge_and_process_cu due to alignment issues with notes,
multiple unspecified types may appear after merging the cus, and
older versions of pahole only support up to one. This is why pahole
1.24 crashes, while newer versions support multiple. However, the
latest version of pahole still does not solve the problem of
incorrect LTO recognition, so compiling the kernel may be slower
than normal."
Even with the newer pahole, the note section misaligment issue still
exists and pahole is misinterpreting the LTO note. Fix it by discarding
the .note.gnu.property section. While GNU properties are important for
user space (and VDSO), they don't seem to have any use for vmlinux.
(In fact, they're already getting (inadvertently) stripped from vmlinux
when CONFIG_DEBUG_INFO_BTF is enabled. The BTF data is extracted from
vmlinux.o with "objcopy --only-section=.BTF" into .btf.vmlinux.bin.o.
That file doesn't have .note.gnu.property, so when it gets modified and
linked back into the main object, the linker automatically strips it
(see "How GNU properties are merged" in the ld man page).)
Reported-by: Daniel Xu <dxu@dxuuu.xyz>
Link: https://lkml.kernel.org/bpf/57830c30-cd77-40cf-9cd1-3bb608aa602e@app.fastmail.com
Debugged-by: Tianyi Liu <i.pear@outlook.com>
Suggested-by: Joan Bruguera Micó <joanbrugueram@gmail.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
v2:
- fixed link
- combined discards
- updated comment
include/asm-generic/vmlinux.lds.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index d1f57e4868ed..cebdf1ca415d 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -891,9 +891,16 @@
/*
* Discard .note.GNU-stack, which is emitted as PROGBITS by the compiler.
* Otherwise, the type of .notes section would become PROGBITS instead of NOTES.
+ *
+ * Also, discard .note.gnu.property, otherwise it forces the notes section to
+ * be 8-byte aligned which causes alignment mismatches with the kernel's custom
+ * 4-byte aligned notes.
*/
#define NOTES \
- /DISCARD/ : { *(.note.GNU-stack) } \
+ /DISCARD/ : { \
+ *(.note.GNU-stack) \
+ *(.note.gnu.property) \
+ } \
.notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
BOUNDED_SECTION_BY(.note.*, _notes) \
} NOTES_HEADERS \
--
2.39.2
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes
2023-04-16 18:52 ` Joan Bruguera Micó
@ 2023-04-27 5:14 ` Joan Bruguera Micó
0 siblings, 0 replies; 30+ messages in thread
From: Joan Bruguera Micó @ 2023-04-27 5:14 UTC (permalink / raw)
To: jpoimboe
Cc: i.pear, acme, alan.maguire, alexandref75, bpf, dxu, jforbes,
linux-kernel, olsajiri, peterz, ptalbert, yhs
PS: As additional information for posterity, there are various conditions that
explain why this is/was only a problem on some specific distributions:
* In addition to dwarves/pahole 1.24, binutils 2.40 seems to also be required
for the problem to occur (in Arch, downgrading to binutils 2.39 fixes it).
* Debian (and thus derived distributions) configures binutils with
`--disable-x86-used-note`, which by default disables emitting the GNU notes
which ultimately cause the .notes section to be aligned to 8 bytes.
On Debian Bookworm & Ubuntu 23.04, the problem reproduces when building like:
```
export KCFLAGS="-Xassembler -mx86-used-note=yes"
export KAFLAGS="-Xassembler -mx86-used-note=yes"
make
```
Finally, here's a smaller .config to reproduce the problem on affected systems:
https://zealcharm.com/20230416-btf-dedup-bug-sample-configs/minimal-repro
^ permalink raw reply [flat|nested] 30+ messages in thread
* [tip: objtool/urgent] vmlinux.lds.h: Discard .note.gnu.property section
2023-01-22 17:48 Kernel build fail with 'btf_encoder__encode: btf__dedup failed!' Daniel Xu
2023-01-22 21:25 ` Daniel Xu
2023-01-23 8:06 ` Jiri Olsa
@ 2023-05-18 11:00 ` tip-bot2 for Josh Poimboeuf
2 siblings, 0 replies; 30+ messages in thread
From: tip-bot2 for Josh Poimboeuf @ 2023-05-18 11:00 UTC (permalink / raw)
To: linux-tip-commits
Cc: Daniel Xu, joanbrugueram, Josh Poimboeuf, x86, linux-kernel
The following commit has been merged into the objtool/urgent branch of tip:
Commit-ID: f7ba52f302fdc392e0047f38e50841483d997144
Gitweb: https://git.kernel.org/tip/f7ba52f302fdc392e0047f38e50841483d997144
Author: Josh Poimboeuf <jpoimboe@kernel.org>
AuthorDate: Tue, 18 Apr 2023 14:49:25 -07:00
Committer: Josh Poimboeuf <jpoimboe@kernel.org>
CommitterDate: Tue, 16 May 2023 06:30:50 -07:00
vmlinux.lds.h: Discard .note.gnu.property section
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
This latter error was caused by pahole crashing when it encountered the
corrupt .notes section. This crash has been fixed in dwarves version
1.25. As Tianyi Liu describes:
"Pahole reads .notes to look for LINUX_ELFNOTE_BUILD_LTO. When LTO is
enabled, pahole needs to call cus__merge_and_process_cu to merge
compile units, at which point there should only be one unspecified
type (used to represent some compilation information) in the global
context.
However, when the kernel is compiled without LTO, if pahole calls
cus__merge_and_process_cu due to alignment issues with notes,
multiple unspecified types may appear after merging the cus, and
older versions of pahole only support up to one. This is why pahole
1.24 crashes, while newer versions support multiple. However, the
latest version of pahole still does not solve the problem of
incorrect LTO recognition, so compiling the kernel may be slower
than normal."
Even with the newer pahole, the note section misaligment issue still
exists and pahole is misinterpreting the LTO note. Fix it by discarding
the .note.gnu.property section. While GNU properties are important for
user space (and VDSO), they don't seem to have any use for vmlinux.
(In fact, they're already getting (inadvertently) stripped from vmlinux
when CONFIG_DEBUG_INFO_BTF is enabled. The BTF data is extracted from
vmlinux.o with "objcopy --only-section=.BTF" into .btf.vmlinux.bin.o.
That file doesn't have .note.gnu.property, so when it gets modified and
linked back into the main object, the linker automatically strips it
(see "How GNU properties are merged" in the ld man page).)
Reported-by: Daniel Xu <dxu@dxuuu.xyz>
Link: https://lkml.kernel.org/bpf/57830c30-cd77-40cf-9cd1-3bb608aa602e@app.fastmail.com
Debugged-by: Tianyi Liu <i.pear@outlook.com>
Suggested-by: Joan Bruguera Micó <joanbrugueram@gmail.com>
Link: https://lore.kernel.org/r/20230418214925.ay3jpf2zhw75kgmd@treble
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
include/asm-generic/vmlinux.lds.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index d1f57e4..cebdf1c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -891,9 +891,16 @@
/*
* Discard .note.GNU-stack, which is emitted as PROGBITS by the compiler.
* Otherwise, the type of .notes section would become PROGBITS instead of NOTES.
+ *
+ * Also, discard .note.gnu.property, otherwise it forces the notes section to
+ * be 8-byte aligned which causes alignment mismatches with the kernel's custom
+ * 4-byte aligned notes.
*/
#define NOTES \
- /DISCARD/ : { *(.note.GNU-stack) } \
+ /DISCARD/ : { \
+ *(.note.GNU-stack) \
+ *(.note.gnu.property) \
+ } \
.notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
BOUNDED_SECTION_BY(.note.*, _notes) \
} NOTES_HEADERS \
^ permalink raw reply related [flat|nested] 30+ messages in thread
end of thread, other threads:[~2023-05-18 11:00 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-22 17:48 Kernel build fail with 'btf_encoder__encode: btf__dedup failed!' Daniel Xu
2023-01-22 21:25 ` Daniel Xu
2023-01-23 8:06 ` Jiri Olsa
2023-01-24 6:13 ` Daniel Xu
2023-01-27 22:28 ` Alexandre Peixoto Ferreira
2023-01-28 0:00 ` Jiri Olsa
2023-01-28 0:21 ` Daniel Xu
2023-01-28 0:23 ` Daniel Xu
2023-01-28 19:23 ` Alexandre Peixoto Ferreira
2023-01-31 15:18 ` Jiri Olsa
2023-02-09 0:21 ` Vicki Pfau
2023-02-09 4:15 ` Alexandre Peixoto Ferreira
2023-02-09 13:07 ` Alan Maguire
2023-02-10 14:02 ` Alexandre Peixoto Ferreira
2023-02-10 14:34 ` Jiri Olsa
2023-02-10 15:37 ` Alexandre Ferreira
2023-02-14 6:33 ` Tianyi Liu
2023-04-11 17:00 ` [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes Josh Poimboeuf
2023-04-12 7:10 ` Tianyi Liu
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ó
2023-05-18 11:00 ` [tip: objtool/urgent] vmlinux.lds.h: Discard .note.gnu.property section tip-bot2 for Josh Poimboeuf
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.