Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

llvm-objcopy: error: unknown argument '--change-section-address' #871

Closed
nathanchance opened this issue Feb 12, 2020 · 12 comments
Closed

llvm-objcopy: error: unknown argument '--change-section-address' #871

nathanchance opened this issue Feb 12, 2020 · 12 comments
Labels
[BUG] llvm A bug that should be fixed in upstream LLVM [FIXED][LINUX] 5.7 This bug was fixed in Linux 5.7 Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list. [TOOL] llvm-objcopy The issue is relevant to LLVM objcopy

Comments

@nathanchance
Copy link
Member

After #779 was resolved for x86_64, I get the following error on 5.6-rc1 with CONFIG_DEBUG_INFO_BTF:

llvm-objcopy: error: unknown argument '--change-section-address'
llvm-objcopy: error: '.btf.vmlinux.bin': No such file or directory
Failed to generate BTF for vmlinux
Try to disable CONFIG_DEBUG_INFO_BTF

This was added in df786c9. Without that commit, the build finishes successfully.

cc @rupprecht
@nathanchance nathanchance added [BUG] Untriaged Something isn't working [TOOL] llvm-objcopy The issue is relevant to LLVM objcopy labels Feb 12, 2020
@nathanchance nathanchance mentioned this issue Mar 16, 2020
Closed
@nickdesaulniers
Copy link
Member

cc @fomichev @MaskRay

@nickdesaulniers
Copy link
Member

nickdesaulniers commented Mar 16, 2020 •
edited by nathanchance
Loading

Filed https://llvm.org/pr45217, too.

@nickdesaulniers nickdesaulniers added [BUG] llvm A bug that should be fixed in upstream LLVM Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list. and removed [BUG] Untriaged Something isn't working labels Mar 16, 2020
@nickdesaulniers
Copy link
Member

@fomichev has a patch internally I've tested, will be sent upstream shortly.

@nickdesaulniers nickdesaulniers added the [PATCH] Exists There is a patch that fixes this issue label Mar 16, 2020
@nickdesaulniers
Copy link
Member

submitted: https://lore.kernel.org/bpf/[email protected]/T/#u

@nickdesaulniers nickdesaulniers added [PATCH] Submitted A patch has been submitted for review and removed [PATCH] Exists There is a patch that fixes this issue labels Mar 16, 2020
@MaskRay
Copy link
Member

MaskRay commented Mar 16, 2020 •
edited
Loading

defconfig + CONFIG_DEBUG_INFO_BTF=y. On Debian, it requires apt install dwarves for pahole.

make CC=clang LD=ld.lld O=/tmp/out/x86_64

+ objcopy --change-section-address .BTF=0 --set-section-flags .BTF=alloc -O binary --only-section=.BTF .tmp_vmlinux.btf .btf.vmlinux.bin
+ objcopy -I binary -O elf64-x86-64 -B x86_64 --rename-section .data=.BTF .btf.vmlinux.bin .btf.vmlinux.bin.o    
objcopy: architecture x86_64 unknown                                       
+ echo 'Failed to generate BTF for vmlinux'

The -B value is incorrect. It should be i386:x86_64. GNU objcopt>=2.34 (https://sourceware.org/bugzilla/show_bug.cgi?id=24968) does not need to specify -B.

A generic --change-section-address is difficult to implement in llvm-objcopy. It can disturb PT_LOAD segments. Currently, only --only-keep-debug can do such sophisticated rewriting of program headers. The semantics of --change-section-vma (ok, this refers to sh_addr) and --change-section-lma (Elf*_Shdr does not record LMA. What does this mean) are not very clear, either.

fengguang pushed a commit to 0day-ci/linux that referenced this issue Mar 17, 2020
@fomichev @intel-lab-lkp
bpf: Support llvm-objcopy for vmlinux BTF
d2770fa 
Commit da5fb18 ("bpf: Support pre-2.25-binutils objcopy for vmlinux
BTF") switched from --dump-section to
--only-section/--change-section-address for BTF export assuming
those ("legacy") options should cover all objcopy versions.

Turns out llvm-objcopy doesn't implement --change-section-address [1],
but it does support --dump-section. Let's partially roll back and
try to use --dump-section first and fall back to
--only-section/--change-section-address for the older binutils.

1. https://bugs.llvm.org/show_bug.cgi?id=45217

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Tested-by: Nick Desaulniers <[email protected]>
Reported-by: Nathan Chancellor <[email protected]>
Link: ClangBuiltLinux#871
Signed-off-by: Stanislav Fomichev <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this issue Mar 17, 2020
@MaskRay @intel-lab-lkp
bpf: Support llvm-objcopy and llvm-objdump for vmlinux BTF
cca5afa 
Simplify gen_btf logic to make it work with llvm-objcopy and
llvm-objdump.  We just need to retain one section .BTF. To do so, we can
use a simple objcopy --only-section=.BTF instead of jumping all the
hoops via an architecture-less binary file.

We use a dd comment to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that .btf.vmlinux.bin.o will be accepted by lld.

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Cc: Stanislav Fomichev <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Reported-by: Nathan Chancellor <[email protected]>
Link: ClangBuiltLinux#871
Signed-off-by: Fangrui Song <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this issue Mar 18, 2020
@MaskRay @intel-lab-lkp
bpf: Support llvm-objcopy for vmlinux BTF
876dc6f 
Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.
'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code can
reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

v6:
- drop llvm-objdump from the title. We don't run objdump now
- delete unused local variables: bin_arch, bin_format and bin_file
- mention in the comment that lld does not allow an ET_EXEC input
- rename BTF back to .BTF . The section name is assumed by bpftool
- add output section description to include/asm-generic/vmlinux.lds.h
- mention cb0cc63 ("powerpc: Include .BTF section")

v5:
- rebase on top of bpf-next/master
- rename .BTF to BTF

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc63 ("powerpc: Include .BTF section")
Link: ClangBuiltLinux#871
Signed-off-by: Fangrui Song <[email protected]>
Reported-by: Nathan Chancellor <[email protected]>
Reviewed-by: Stanislav Fomichev <[email protected]>
Tested-by: Stanislav Fomichev <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Andrii Nakryiko <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Naveen N. Rao <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Cc: [email protected]
@nathanchance
Copy link
Member Author

https://lore.kernel.org/netdev/[email protected]/

should fix llvm-objcopy with BTF. I should be able to test in the morning.

@MaskRay
Copy link
Member

MaskRay commented Mar 19, 2020

https://lore.kernel.org/netdev/[email protected]/

should fix llvm-objcopy with BTF. I should be able to test in the morning.

Thanks! Your test instructions will also be very helpful to me.. I got some trouble because I only started to know how to send a patch at v5.

@nickdesaulniers
Copy link
Member

accepted: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=90ceddcb495008ac8ba7a3dce297841efcd7d584

Congrats @MaskRay ! Is that your first Linux kernel patch?

@nickdesaulniers nickdesaulniers added [PATCH] Accepted A submitted patch has been accepted upstream and removed [PATCH] Submitted A patch has been submitted for review labels Mar 19, 2020
@MaskRay
Copy link
Member

MaskRay commented Mar 19, 2020

accepted: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=90ceddcb495008ac8ba7a3dce297841efcd7d584

Congrats @MaskRay ! Is that your first Linux kernel patch?

If bpf-next/master is a -next tree, then yes for the Linux kernel patch merged into a -next tree.

From https://www.kernel.org/doc/html/latest/process/2.Process.html#staging-trees

When the merge window opens, top-level maintainers will ask Linus to “pull” the patches they have selected for merging from their repositories. If Linus agrees, the stream of patches will flow up into his repository, becoming part of the mainline kernel. The amount of attention that Linus pays to specific patches received in a pull operation varies. It is clear that, sometimes, he looks quite closely. But, as a general rule, Linus trusts the subsystem maintainers to not send bad patches upstream.

Perhaps only after the whole process I can say yes..

fengguang pushed a commit to 0day-ci/linux that referenced this issue Mar 19, 2020
@MaskRay @borkmann
bpf: Support llvm-objcopy for vmlinux BTF
90ceddc 
Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc63 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor <[email protected]>
Signed-off-by: Fangrui Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Stanislav Fomichev <[email protected]>
Tested-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Stanislav Fomichev <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Link: ClangBuiltLinux#871
Link: https://lore.kernel.org/bpf/[email protected]
@nathanchance
Copy link
Member Author

The reason Linux is concerned with this flag has been resolved and merged into mainline: https://git.kernel.org/linus/90ceddcb495008ac8ba7a3dce297841efcd7d584

Closing this here, the upstream LLVM bug can be used to further track implementation of this flag.

@nathanchance nathanchance added [FIXED][LINUX] 5.7 This bug was fixed in Linux 5.7 and removed [PATCH] Accepted A submitted patch has been accepted upstream labels Apr 1, 2020
mariateguiani pushed a commit to mariateguiani/kernel_common that referenced this issue May 31, 2020
@MaskRay @mariateguiani
bpf: Support llvm-objcopy for vmlinux BTF
00419a1 
Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc63 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor <[email protected]>
Signed-off-by: Fangrui Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Stanislav Fomichev <[email protected]>
Tested-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Stanislav Fomichev <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Link: ClangBuiltLinux/linux#871
Link: https://lore.kernel.org/bpf/[email protected]
mariateguiani pushed a commit to mariateguiani/kernel_common that referenced this issue Jun 4, 2020
@MaskRay @mariateguiani
bpf: Support llvm-objcopy for vmlinux BTF
35c6b54 
Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc63 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor <[email protected]>
Signed-off-by: Fangrui Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Stanislav Fomichev <[email protected]>
Tested-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Stanislav Fomichev <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Link: ClangBuiltLinux/linux#871
Link: https://lore.kernel.org/bpf/[email protected]
(cherry picked from commit 90ceddc)
Signed-off-by: Maria Teguiani <[email protected]>
Change-Id: I92492e2fcdac277f0a44d68345b9c7676e9405b7
mariateguiani pushed a commit to mariateguiani/kernel_common that referenced this issue Jun 4, 2020
@MaskRay @mariateguiani
bpf: Support llvm-objcopy for vmlinux BTF
02fffc2 
Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc63 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor <[email protected]>
Signed-off-by: Fangrui Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Stanislav Fomichev <[email protected]>
Tested-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Stanislav Fomichev <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Link: ClangBuiltLinux/linux#871
Link: https://lore.kernel.org/bpf/[email protected]
(cherry picked from commit 90ceddc)
Signed-off-by: Maria Teguiani <[email protected]>
Change-Id: I92492e2fcdac277f0a44d68345b9c7676e9405b7
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Jun 17, 2020
@MaskRay @gregkh
bpf: Support llvm-objcopy for vmlinux BTF
18c311e 
commit 90ceddc upstream.

Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc63 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor <[email protected]>
Signed-off-by: Fangrui Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Stanislav Fomichev <[email protected]>
Tested-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Stanislav Fomichev <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Link: ClangBuiltLinux/linux#871
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Maria Teguiani <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista that referenced this issue Jul 15, 2020
@MaskRay @mvakuster
bpf: Support llvm-objcopy for vmlinux BTF
844c070 
Source: Kernel.org
MR: 103311
Type: Integration
Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y
ChangeID: f04d1e880f17b935b5a181d446ff82b4193eee85
Description:

commit 90ceddc upstream.

Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc63 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor <[email protected]>
Signed-off-by: Fangrui Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Stanislav Fomichev <[email protected]>
Tested-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Stanislav Fomichev <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Link: ClangBuiltLinux/linux#871
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Maria Teguiani <[email protected]>
Tested-by: Matthias Maennich <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista that referenced this issue Jul 15, 2020
@MaskRay @mvakuster
bpf: Support llvm-objcopy for vmlinux BTF
e524c49 
Source: Kernel.org
MR: 103311
Type: Integration
Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y
ChangeID: f04d1e880f17b935b5a181d446ff82b4193eee85
Description:

commit 90ceddc upstream.

Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc63 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor <[email protected]>
Signed-off-by: Fangrui Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Stanislav Fomichev <[email protected]>
Tested-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Stanislav Fomichev <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Link: ClangBuiltLinux/linux#871
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Maria Teguiani <[email protected]>
Tested-by: Matthias Maennich <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
nathanchance pushed a commit that referenced this issue Jul 18, 2020
@dcaratti @davem330
bnxt_en: fix NULL dereference in case SR-IOV configuration fails
c8b1d74 
we need to set 'active_vfs' back to 0, if something goes wrong during the
allocation of SR-IOV resources: otherwise, further VF configurations will
wrongly assume that bp->pf.vf[x] are valid memory locations, and commands
like the ones in the following sequence:

 # echo 2 >/sys/bus/pci/devices/${ADDR}/sriov_numvfs
 # ip link set dev ens1f0np0 up
 # ip link set dev ens1f0np0 vf 0 trust on

will cause a kernel crash similar to this:

 bnxt_en 0000:3b:00.0: not enough MMIO resources for SR-IOV
 BUG: kernel NULL pointer dereference, address: 0000000000000014
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] SMP PTI
 CPU: 43 PID: 2059 Comm: ip Tainted: G          I       5.8.0-rc2.upstream+ #871
 Hardware name: Dell Inc. PowerEdge R740/08D89F, BIOS 2.2.11 06/13/2019
 RIP: 0010:bnxt_set_vf_trust+0x5b/0x110 [bnxt_en]
 Code: 44 24 58 31 c0 e8 f5 fb ff ff 85 c0 0f 85 b6 00 00 00 48 8d 1c 5b 41 89 c6 b9 0b 00 00 00 48 c1 e3 04 49 03 9c 24 f0 0e 00 00 <8b> 43 14 89 c2 83 c8 10 83 e2 ef 45 84 ed 49 89 e5 0f 44 c2 4c 89
 RSP: 0018:ffffac6246a1f570 EFLAGS: 00010246
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000b
 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff98b28f538900
 RBP: ffff98b28f538900 R08: 0000000000000000 R09: 0000000000000008
 R10: ffffffffb9515be0 R11: ffffac6246a1f678 R12: ffff98b28f538000
 R13: 0000000000000001 R14: 0000000000000000 R15: ffffffffc05451e0
 FS:  00007fde0f688800(0000) GS:ffff98baffd40000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000014 CR3: 000000104bb0a003 CR4: 00000000007606e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  do_setlink+0x994/0xfe0
  __rtnl_newlink+0x544/0x8d0
  rtnl_newlink+0x47/0x70
  rtnetlink_rcv_msg+0x29f/0x350
  netlink_rcv_skb+0x4a/0x110
  netlink_unicast+0x21d/0x300
  netlink_sendmsg+0x329/0x450
  sock_sendmsg+0x5b/0x60
  ____sys_sendmsg+0x204/0x280
  ___sys_sendmsg+0x88/0xd0
  __sys_sendmsg+0x5e/0xa0
  do_syscall_64+0x47/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: c0c050c ("bnxt_en: New Broadcom ethernet driver.")
Reported-by: Fei Liu <[email protected]>
CC: Jonathan Toppins <[email protected]>
CC: Michael Chan <[email protected]>
Signed-off-by: Davide Caratti <[email protected]>
Reviewed-by: Michael Chan <[email protected]>
Acked-by: Jonathan Toppins <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
taiten pushed a commit to taiten/ubuntu-kernel-focal that referenced this issue Aug 13, 2020
@MaskRay @kelmously
bpf: Support llvm-objcopy for vmlinux BTF
087a8df 
BugLink: https://bugs.launchpad.net/bugs/1884089

commit 90ceddcb495008ac8ba7a3dce297841efcd7d584 upstream.

Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9b9476 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc635c7a9 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor <[email protected]>
Signed-off-by: Fangrui Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Stanislav Fomichev <[email protected]>
Tested-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Stanislav Fomichev <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Link: ClangBuiltLinux/linux#871
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Maria Teguiani <[email protected]>
Tested-by: Matthias Maennich <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Khalid Elmously <[email protected]>
@nickdesaulniers
Copy link
Member

FWIW: the upstream issue was fixed recently via: llvm/llvm-project@2b2f4ae. Did https://lore.kernel.org/bpf/[email protected]/ land upstream?

90ceddc is FWICT what landed upstream from the discussion on https://lore.kernel.org/bpf/[email protected]/.

@nathanchance
Copy link
Member Author

Yup, https://git.kernel.org/linus/90ceddcb495008ac8ba7a3dce297841efcd7d584 in 5.7 avoided this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[BUG] llvm A bug that should be fixed in upstream LLVM [FIXED][LINUX] 5.7 This bug was fixed in Linux 5.7 Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list. [TOOL] llvm-objcopy The issue is relevant to LLVM objcopy
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@MaskRay @nickdesaulniers @nathanchance