| Message ID | 20190402164950.429597-1-andrii.nakryiko@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | [bpf-next] kbuild: add ability to generate BTF type info for vmlinux | expand |
From: <andrii.nakryiko@gmail.com> Date: Tue, 2 Apr 2019 09:49:50 -0700 > From: Andrii Nakryiko <andriin@fb.com> > > This patch adds new config option to trigger generation of BTF type > information from DWARF debuginfo for vmlinux and kernel modules through > pahole, which in turn relies on libbpf for btf_dedup() algorithm. > > The intent is to record compact type information of all types used > inside kernel, including all the structs/unions/typedefs/etc. This > enables BPF's compile-once-run-everywhere ([0]) approach, in which > tracing programs that are inspecting kernel's internal data (e.g., > struct task_struct) can be compiled on a system running some kernel > version, but would be possible to run on other kernel versions (and > configurations) without recompilation, even if the layout of structs > changed and/or some of the fields were added, removed, or renamed. > > This is only possible if BPF loader can get kernel type info to adjust > all the offsets correctly. This patch is a first time in this direction, > making sure that BTF type info is part of Linux kernel image in > non-loadable ELF section. > > BTF deduplication ([1]) algorithm typically provides 100x savings > compared to DWARF data, so resulting .BTF section is not big as is > typically about 2MB in size. > > [0] http://vger.kernel.org/lpc-bpf2018.html#session-2 > [1] https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html > > Signed-off-by: Andrii Nakryiko <andriin@fb.com> Acked-by: David S. Miller <davem@davemloft.net>
On 04/02/2019 06:49 PM, andrii.nakryiko@gmail.com wrote: > From: Andrii Nakryiko <andriin@fb.com> > > This patch adds new config option to trigger generation of BTF type > information from DWARF debuginfo for vmlinux and kernel modules through > pahole, which in turn relies on libbpf for btf_dedup() algorithm. > > The intent is to record compact type information of all types used > inside kernel, including all the structs/unions/typedefs/etc. This > enables BPF's compile-once-run-everywhere ([0]) approach, in which > tracing programs that are inspecting kernel's internal data (e.g., > struct task_struct) can be compiled on a system running some kernel > version, but would be possible to run on other kernel versions (and > configurations) without recompilation, even if the layout of structs > changed and/or some of the fields were added, removed, or renamed. > > This is only possible if BPF loader can get kernel type info to adjust > all the offsets correctly. This patch is a first time in this direction, > making sure that BTF type info is part of Linux kernel image in > non-loadable ELF section. > > BTF deduplication ([1]) algorithm typically provides 100x savings > compared to DWARF data, so resulting .BTF section is not big as is > typically about 2MB in size. > > [0] http://vger.kernel.org/lpc-bpf2018.html#session-2 > [1] https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html > > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > Cc: Arnaldo Carvalho de Melo <acme@redhat.com> > Cc: Daniel Borkmann <daniel@iogearbox.net> > Cc: Alexei Starovoitov <ast@fb.com> > Cc: Yonghong Song <yhs@fb.com> > Cc: Martin KaFai Lau <kafai@fb.com> > Signed-off-by: Andrii Nakryiko <andriin@fb.com> LGTM! As subject is targetting bpf-next this time since this BPF-related patch in this form has been sitting on the list for over 1.5months, I've taken it in there now, thanks!
On Tue, Apr 02, 2019 at 09:49:50AM -0700, andrii.nakryiko@gmail.com wrote: > From: Andrii Nakryiko <andriin@fb.com> > > This patch adds new config option to trigger generation of BTF type > information from DWARF debuginfo for vmlinux and kernel modules through > pahole, which in turn relies on libbpf for btf_dedup() algorithm. > > The intent is to record compact type information of all types used > inside kernel, including all the structs/unions/typedefs/etc. This > enables BPF's compile-once-run-everywhere ([0]) approach, in which > tracing programs that are inspecting kernel's internal data (e.g., > struct task_struct) can be compiled on a system running some kernel > version, but would be possible to run on other kernel versions (and > configurations) without recompilation, even if the layout of structs > changed and/or some of the fields were added, removed, or renamed. > > This is only possible if BPF loader can get kernel type info to adjust > all the offsets correctly. This patch is a first time in this direction, > making sure that BTF type info is part of Linux kernel image in > non-loadable ELF section. > > BTF deduplication ([1]) algorithm typically provides 100x savings > compared to DWARF data, so resulting .BTF section is not big as is > typically about 2MB in size. hi, I'm using the latest pahole from git tree: https://github.com/acmel/dwarves.git and getting pahole crash: LD vmlinux BTF vmlinux die__process_inline_expansion: DW_TAG_label (0xa) @ <0x3eef8> not handled! scripts/link-vmlinux.sh: line 96: 31222 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} make[1]: *** [/home/jolsa/linux/Makefile:1025: vmlinux] Error 139 make: *** [Makefile:170: sub-make] Error 2 is there some other source/dependency I'm missing? thanks, jirka > > [0] http://vger.kernel.org/lpc-bpf2018.html#session-2 > [1] https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html > > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > Cc: Arnaldo Carvalho de Melo <acme@redhat.com> > Cc: Daniel Borkmann <daniel@iogearbox.net> > Cc: Alexei Starovoitov <ast@fb.com> > Cc: Yonghong Song <yhs@fb.com> > Cc: Martin KaFai Lau <kafai@fb.com> > Signed-off-by: Andrii Nakryiko <andriin@fb.com> > --- > Makefile | 3 ++- > lib/Kconfig.debug | 8 ++++++++ > scripts/link-vmlinux.sh | 20 +++++++++++++++++++- > 3 files changed, 29 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index d5713e7b1e50..a55308147a09 100644 > --- a/Makefile > +++ b/Makefile > @@ -387,6 +387,7 @@ NM = $(CROSS_COMPILE)nm > STRIP = $(CROSS_COMPILE)strip > OBJCOPY = $(CROSS_COMPILE)objcopy > OBJDUMP = $(CROSS_COMPILE)objdump > +PAHOLE = pahole > LEX = flex > YACC = bison > AWK = awk > @@ -442,7 +443,7 @@ KBUILD_LDFLAGS := > GCC_PLUGINS_CFLAGS := > > export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC > -export CPP AR NM STRIP OBJCOPY OBJDUMP KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS > +export CPP AR NM STRIP OBJCOPY OBJDUMP PAHOLE KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS > export MAKE LEX YACC AWK GENKSYMS INSTALLKERNEL PERL PYTHON PYTHON2 PYTHON3 UTS_MACHINE > export HOSTCXX KBUILD_HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index d4df5b24d75e..cce78dcd19a2 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -200,6 +200,14 @@ config DEBUG_INFO_DWARF4 > But it significantly improves the success of resolving > variables in gdb on optimized code. > > +config DEBUG_INFO_BTF > + bool "Generate BTF typeinfo" > + depends on DEBUG_INFO > + help > + Generate deduplicated BTF type information from DWARF debug info. > + Turning this on expects presence of pahole tool, which will convert > + DWARF type info into equivalent deduplicated BTF type info. > + > config GDB_SCRIPTS > bool "Provide GDB scripts for kernel debugging" > depends on DEBUG_INFO > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > index c8cf45362bd6..73bb7dfdc2c9 100755 > --- a/scripts/link-vmlinux.sh > +++ b/scripts/link-vmlinux.sh > @@ -40,7 +40,7 @@ set -e > info() > { > if [ "${quiet}" != "silent_" ]; then > - printf " %-7s %s\n" ${1} ${2} > + printf " %-7s %s\n" "${1}" "${2}" > fi > } > > @@ -114,6 +114,20 @@ vmlinux_link() > fi > } > > +# generate .BTF typeinfo from DWARF debuginfo > +gen_btf() > +{ > + local pahole_ver; > + > + pahole_ver=$(${PAHOLE} --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/') > + if [ "${pahole_ver}" -lt "113" ]; then > + info "BTF" "${1}: pahole version $(${PAHOLE} --version) is too old, need at least v1.13" > + exit 0 > + fi > + > + info "BTF" ${1} > + LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} > +} > > # Create ${2} .o file with all symbols from the ${1} object file > kallsyms() > @@ -281,6 +295,10 @@ fi > info LD vmlinux > vmlinux_link "${kallsymso}" vmlinux > > +if [ -n "${CONFIG_DEBUG_INFO_BTF}" ]; then > + gen_btf vmlinux > +fi > + > if [ -n "${CONFIG_BUILDTIME_EXTABLE_SORT}" ]; then > info SORTEX vmlinux > sortextable vmlinux > -- > 2.17.1 >
On 04/03/2019 10:46 AM, Jiri Olsa wrote: > On Tue, Apr 02, 2019 at 09:49:50AM -0700, andrii.nakryiko@gmail.com wrote: >> From: Andrii Nakryiko <andriin@fb.com> >> >> This patch adds new config option to trigger generation of BTF type >> information from DWARF debuginfo for vmlinux and kernel modules through >> pahole, which in turn relies on libbpf for btf_dedup() algorithm. >> >> The intent is to record compact type information of all types used >> inside kernel, including all the structs/unions/typedefs/etc. This >> enables BPF's compile-once-run-everywhere ([0]) approach, in which >> tracing programs that are inspecting kernel's internal data (e.g., >> struct task_struct) can be compiled on a system running some kernel >> version, but would be possible to run on other kernel versions (and >> configurations) without recompilation, even if the layout of structs >> changed and/or some of the fields were added, removed, or renamed. >> >> This is only possible if BPF loader can get kernel type info to adjust >> all the offsets correctly. This patch is a first time in this direction, >> making sure that BTF type info is part of Linux kernel image in >> non-loadable ELF section. >> >> BTF deduplication ([1]) algorithm typically provides 100x savings >> compared to DWARF data, so resulting .BTF section is not big as is >> typically about 2MB in size. > > hi, > I'm using the latest pahole from git tree: > https://github.com/acmel/dwarves.git > > and getting pahole crash: > > LD vmlinux > BTF vmlinux > die__process_inline_expansion: DW_TAG_label (0xa) @ <0x3eef8> not handled! > scripts/link-vmlinux.sh: line 96: 31222 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} > make[1]: *** [/home/jolsa/linux/Makefile:1025: vmlinux] Error 139 > make: *** [Makefile:170: sub-make] Error 2 > > is there some other source/dependency I'm missing? Yesterday night, I've tested with [0] but seems to have the same HEAD as the github repo you pointed out. Seems the above is coming from pahole's __die__process_tag() bailing out with default for DW_TAG_label? On my side worked fine: # rm vmlinux # make -j8 DESCEND objtool CALL scripts/atomic/check-atomics.sh CALL scripts/checksyscalls.sh CHK include/generated/compile.h GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o AR init/built-in.a LD vmlinux.o MODPOST vmlinux.o KSYM .tmp_kallsyms1.o KSYM .tmp_kallsyms2.o LD vmlinux BTF vmlinux <-- SORTEX vmlinux SYSMAP System.map Building modules, stage 2. CC arch/x86/boot/version.o VOFFSET arch/x86/boot/compressed/../voffset.h OBJCOPY arch/x86/boot/compressed/vmlinux.bin RELOCS arch/x86/boot/compressed/vmlinux.relocs CC arch/x86/boot/compressed/kaslr.o CC arch/x86/boot/compressed/misc.o GZIP arch/x86/boot/compressed/vmlinux.bin.gz MKPIGGY arch/x86/boot/compressed/piggy.S AS arch/x86/boot/compressed/piggy.o LD arch/x86/boot/compressed/vmlinux ZOFFSET arch/x86/boot/zoffset.h OBJCOPY arch/x86/boot/vmlinux.bin AS arch/x86/boot/header.o LD arch/x86/boot/setup.elf OBJCOPY arch/x86/boot/setup.bin BUILD arch/x86/boot/bzImage Setup is 17660 bytes (padded to 17920 bytes). System is 9245 kB CRC 24cd7eff Kernel: arch/x86/boot/bzImage is ready (#15) MODPOST 4979 modules [0] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/
On Wed, Apr 03, 2019 at 11:04:28AM +0200, Daniel Borkmann wrote: > On 04/03/2019 10:46 AM, Jiri Olsa wrote: > > On Tue, Apr 02, 2019 at 09:49:50AM -0700, andrii.nakryiko@gmail.com wrote: > >> From: Andrii Nakryiko <andriin@fb.com> > >> > >> This patch adds new config option to trigger generation of BTF type > >> information from DWARF debuginfo for vmlinux and kernel modules through > >> pahole, which in turn relies on libbpf for btf_dedup() algorithm. > >> > >> The intent is to record compact type information of all types used > >> inside kernel, including all the structs/unions/typedefs/etc. This > >> enables BPF's compile-once-run-everywhere ([0]) approach, in which > >> tracing programs that are inspecting kernel's internal data (e.g., > >> struct task_struct) can be compiled on a system running some kernel > >> version, but would be possible to run on other kernel versions (and > >> configurations) without recompilation, even if the layout of structs > >> changed and/or some of the fields were added, removed, or renamed. > >> > >> This is only possible if BPF loader can get kernel type info to adjust > >> all the offsets correctly. This patch is a first time in this direction, > >> making sure that BTF type info is part of Linux kernel image in > >> non-loadable ELF section. > >> > >> BTF deduplication ([1]) algorithm typically provides 100x savings > >> compared to DWARF data, so resulting .BTF section is not big as is > >> typically about 2MB in size. > > > > hi, > > I'm using the latest pahole from git tree: > > https://github.com/acmel/dwarves.git > > > > and getting pahole crash: > > > > LD vmlinux > > BTF vmlinux > > die__process_inline_expansion: DW_TAG_label (0xa) @ <0x3eef8> not handled! > > scripts/link-vmlinux.sh: line 96: 31222 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} > > make[1]: *** [/home/jolsa/linux/Makefile:1025: vmlinux] Error 139 > > make: *** [Makefile:170: sub-make] Error 2 > > > > is there some other source/dependency I'm missing? > > Yesterday night, I've tested with [0] but seems to have the same HEAD as > the github repo you pointed out. Seems the above is coming from pahole's > __die__process_tag() bailing out with default for DW_TAG_label? > > On my side worked fine: hum, I also had to change the version of pahole in the patch to allow version v1.12, because both latest pahole sources are on version 1.12, did u have to do that? looks like there's v1.13 somewhere ;-) jirka SNIP > > [0] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/
On 04/03/2019 11:12 AM, Jiri Olsa wrote: > On Wed, Apr 03, 2019 at 11:04:28AM +0200, Daniel Borkmann wrote: >> On 04/03/2019 10:46 AM, Jiri Olsa wrote: >>> On Tue, Apr 02, 2019 at 09:49:50AM -0700, andrii.nakryiko@gmail.com wrote: >>>> From: Andrii Nakryiko <andriin@fb.com> >>>> >>>> This patch adds new config option to trigger generation of BTF type >>>> information from DWARF debuginfo for vmlinux and kernel modules through >>>> pahole, which in turn relies on libbpf for btf_dedup() algorithm. >>>> >>>> The intent is to record compact type information of all types used >>>> inside kernel, including all the structs/unions/typedefs/etc. This >>>> enables BPF's compile-once-run-everywhere ([0]) approach, in which >>>> tracing programs that are inspecting kernel's internal data (e.g., >>>> struct task_struct) can be compiled on a system running some kernel >>>> version, but would be possible to run on other kernel versions (and >>>> configurations) without recompilation, even if the layout of structs >>>> changed and/or some of the fields were added, removed, or renamed. >>>> >>>> This is only possible if BPF loader can get kernel type info to adjust >>>> all the offsets correctly. This patch is a first time in this direction, >>>> making sure that BTF type info is part of Linux kernel image in >>>> non-loadable ELF section. >>>> >>>> BTF deduplication ([1]) algorithm typically provides 100x savings >>>> compared to DWARF data, so resulting .BTF section is not big as is >>>> typically about 2MB in size. >>> >>> hi, >>> I'm using the latest pahole from git tree: >>> https://github.com/acmel/dwarves.git >>> >>> and getting pahole crash: >>> >>> LD vmlinux >>> BTF vmlinux >>> die__process_inline_expansion: DW_TAG_label (0xa) @ <0x3eef8> not handled! >>> scripts/link-vmlinux.sh: line 96: 31222 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} >>> make[1]: *** [/home/jolsa/linux/Makefile:1025: vmlinux] Error 139 >>> make: *** [Makefile:170: sub-make] Error 2 >>> >>> is there some other source/dependency I'm missing? >> >> Yesterday night, I've tested with [0] but seems to have the same HEAD as >> the github repo you pointed out. Seems the above is coming from pahole's >> __die__process_tag() bailing out with default for DW_TAG_label? >> >> On my side worked fine: > > hum, I also had to change the version of pahole in the patch to allow > version v1.12, because both latest pahole sources are on version 1.12, > did u have to do that? looks like there's v1.13 somewhere ;-) Yeah, I did for local testing. Tag still needs to be bumped by Arnaldo.
Em Wed, Apr 03, 2019 at 11:12:58AM +0200, Jiri Olsa escreveu: > On Wed, Apr 03, 2019 at 11:04:28AM +0200, Daniel Borkmann wrote: > > On 04/03/2019 10:46 AM, Jiri Olsa wrote: > > > On Tue, Apr 02, 2019 at 09:49:50AM -0700, andrii.nakryiko@gmail.com wrote: > > >> From: Andrii Nakryiko <andriin@fb.com> > > >> > > >> This patch adds new config option to trigger generation of BTF type > > >> information from DWARF debuginfo for vmlinux and kernel modules through > > >> pahole, which in turn relies on libbpf for btf_dedup() algorithm. > > >> > > >> The intent is to record compact type information of all types used > > >> inside kernel, including all the structs/unions/typedefs/etc. This > > >> enables BPF's compile-once-run-everywhere ([0]) approach, in which > > >> tracing programs that are inspecting kernel's internal data (e.g., > > >> struct task_struct) can be compiled on a system running some kernel > > >> version, but would be possible to run on other kernel versions (and > > >> configurations) without recompilation, even if the layout of structs > > >> changed and/or some of the fields were added, removed, or renamed. > > >> > > >> This is only possible if BPF loader can get kernel type info to adjust > > >> all the offsets correctly. This patch is a first time in this direction, > > >> making sure that BTF type info is part of Linux kernel image in > > >> non-loadable ELF section. > > >> > > >> BTF deduplication ([1]) algorithm typically provides 100x savings > > >> compared to DWARF data, so resulting .BTF section is not big as is > > >> typically about 2MB in size. > > > > > > hi, > > > I'm using the latest pahole from git tree: > > > https://github.com/acmel/dwarves.git > > > > > > and getting pahole crash: > > > > > > LD vmlinux > > > BTF vmlinux > > > die__process_inline_expansion: DW_TAG_label (0xa) @ <0x3eef8> not handled! > > > scripts/link-vmlinux.sh: line 96: 31222 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} > > > make[1]: *** [/home/jolsa/linux/Makefile:1025: vmlinux] Error 139 > > > make: *** [Makefile:170: sub-make] Error 2 > > > > > > is there some other source/dependency I'm missing? > > > > Yesterday night, I've tested with [0] but seems to have the same HEAD as > > the github repo you pointed out. Seems the above is coming from pahole's > > __die__process_tag() bailing out with default for DW_TAG_label? > > > > On my side worked fine: > > hum, I also had to change the version of pahole in the patch to allow > version v1.12, because both latest pahole sources are on version 1.12, > did u have to do that? looks like there's v1.13 somewhere ;-) I'll get the --reorganize algorithm simplified to cope with some internal changes needed for the BTF encoding/decoding and tag v1.13 later today, max late this week. Then I'll go back adding the bitfield reorganization bits that will take a bit more work. Hopefully this way we get something to work with the Kbuild changes and have progress in that front. I'll look at the DW_TAG_label case too, please send me me in PVT the vmlinux file with that problem so that I can analyse it. > jirka > > SNIP > > > > > [0] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/
Em Wed, Apr 03, 2019 at 11:12:58AM +0200, Jiri Olsa escreveu: > On Wed, Apr 03, 2019 at 11:04:28AM +0200, Daniel Borkmann wrote: > > On 04/03/2019 10:46 AM, Jiri Olsa wrote: > > > On Tue, Apr 02, 2019 at 09:49:50AM -0700, andrii.nakryiko@gmail.com wrote: > > >> From: Andrii Nakryiko <andriin@fb.com> > > >> > > >> This patch adds new config option to trigger generation of BTF type > > >> information from DWARF debuginfo for vmlinux and kernel modules through > > >> pahole, which in turn relies on libbpf for btf_dedup() algorithm. > > > I'm using the latest pahole from git tree: > > > https://github.com/acmel/dwarves.git I've updated this oen as well, but the canonical one is at: git://git.kernel.org/pub/scm/devel/pahole/pahole.git See the fix below. > > > and getting pahole crash: > > > LD vmlinux > > > BTF vmlinux > > > die__process_inline_expansion: DW_TAG_label (0xa) @ <0x3eef8> not handled! > > > scripts/link-vmlinux.sh: line 96: 31222 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} > > > make[1]: *** [/home/jolsa/linux/Makefile:1025: vmlinux] Error 139 > > > make: *** [Makefile:170: sub-make] Error 2 > > > is there some other source/dependency I'm missing? > > Yesterday night, I've tested with [0] but seems to have the same HEAD as > > the github repo you pointed out. Seems the above is coming from pahole's > > __die__process_tag() bailing out with default for DW_TAG_label? > > On my side worked fine: > hum, I also had to change the version of pahole in the patch to allow > version v1.12, because both latest pahole sources are on version 1.12, > did u have to do that? looks like there's v1.13 somewhere ;-) So, I've reproduced the problem and fixed it, please pull my latest master branch from git://git.kernel.org/pub/scm/devel/pahole/pahole.git, please do the hack to make it expect v1.12, I'll try and relase v1.13 soon, if nothing else pops up soon. Thanks for the report! - Arnaldo
On Wed, Apr 03, 2019 at 09:40:42PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Apr 03, 2019 at 11:12:58AM +0200, Jiri Olsa escreveu: > > On Wed, Apr 03, 2019 at 11:04:28AM +0200, Daniel Borkmann wrote: > > > On 04/03/2019 10:46 AM, Jiri Olsa wrote: > > > > On Tue, Apr 02, 2019 at 09:49:50AM -0700, andrii.nakryiko@gmail.com wrote: > > > >> From: Andrii Nakryiko <andriin@fb.com> > > > >> > > > >> This patch adds new config option to trigger generation of BTF type > > > >> information from DWARF debuginfo for vmlinux and kernel modules through > > > >> pahole, which in turn relies on libbpf for btf_dedup() algorithm. > > > > I'm using the latest pahole from git tree: > > > > > https://github.com/acmel/dwarves.git > > I've updated this oen as well, but the canonical one is at: > > git://git.kernel.org/pub/scm/devel/pahole/pahole.git > > See the fix below. > > > > > and getting pahole crash: > > > > > LD vmlinux > > > > BTF vmlinux > > > > die__process_inline_expansion: DW_TAG_label (0xa) @ <0x3eef8> not handled! > > > > scripts/link-vmlinux.sh: line 96: 31222 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} > > > > make[1]: *** [/home/jolsa/linux/Makefile:1025: vmlinux] Error 139 > > > > make: *** [Makefile:170: sub-make] Error 2 > > > > > is there some other source/dependency I'm missing? > > > > Yesterday night, I've tested with [0] but seems to have the same HEAD as > > > the github repo you pointed out. Seems the above is coming from pahole's > > > __die__process_tag() bailing out with default for DW_TAG_label? > > > > On my side worked fine: > > > hum, I also had to change the version of pahole in the patch to allow > > version v1.12, because both latest pahole sources are on version 1.12, > > did u have to do that? looks like there's v1.13 somewhere ;-) > > So, I've reproduced the problem and fixed it, please pull my latest > master branch from git://git.kernel.org/pub/scm/devel/pahole/pahole.git, > please do the hack to make it expect v1.12, I'll try and relase v1.13 > soon, if nothing else pops up soon. ... LD vmlinux BTF vmlinux SORTEX vmlinux works nicely now, thanks ;-) jirka
diff --git a/Makefile b/Makefile index d5713e7b1e50..a55308147a09 100644 --- a/Makefile +++ b/Makefile @@ -387,6 +387,7 @@ NM = $(CROSS_COMPILE)nm STRIP = $(CROSS_COMPILE)strip OBJCOPY = $(CROSS_COMPILE)objcopy OBJDUMP = $(CROSS_COMPILE)objdump +PAHOLE = pahole LEX = flex YACC = bison AWK = awk @@ -442,7 +443,7 @@ KBUILD_LDFLAGS := GCC_PLUGINS_CFLAGS := export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC -export CPP AR NM STRIP OBJCOPY OBJDUMP KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS +export CPP AR NM STRIP OBJCOPY OBJDUMP PAHOLE KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS export MAKE LEX YACC AWK GENKSYMS INSTALLKERNEL PERL PYTHON PYTHON2 PYTHON3 UTS_MACHINE export HOSTCXX KBUILD_HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index d4df5b24d75e..cce78dcd19a2 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -200,6 +200,14 @@ config DEBUG_INFO_DWARF4 But it significantly improves the success of resolving variables in gdb on optimized code. +config DEBUG_INFO_BTF + bool "Generate BTF typeinfo" + depends on DEBUG_INFO + help + Generate deduplicated BTF type information from DWARF debug info. + Turning this on expects presence of pahole tool, which will convert + DWARF type info into equivalent deduplicated BTF type info. + config GDB_SCRIPTS bool "Provide GDB scripts for kernel debugging" depends on DEBUG_INFO diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh index c8cf45362bd6..73bb7dfdc2c9 100755 --- a/scripts/link-vmlinux.sh +++ b/scripts/link-vmlinux.sh @@ -40,7 +40,7 @@ set -e info() { if [ "${quiet}" != "silent_" ]; then - printf " %-7s %s\n" ${1} ${2} + printf " %-7s %s\n" "${1}" "${2}" fi } @@ -114,6 +114,20 @@ vmlinux_link() fi } +# generate .BTF typeinfo from DWARF debuginfo +gen_btf() +{ + local pahole_ver; + + pahole_ver=$(${PAHOLE} --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/') + if [ "${pahole_ver}" -lt "113" ]; then + info "BTF" "${1}: pahole version $(${PAHOLE} --version) is too old, need at least v1.13" + exit 0 + fi + + info "BTF" ${1} + LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} +} # Create ${2} .o file with all symbols from the ${1} object file kallsyms() @@ -281,6 +295,10 @@ fi info LD vmlinux vmlinux_link "${kallsymso}" vmlinux +if [ -n "${CONFIG_DEBUG_INFO_BTF}" ]; then + gen_btf vmlinux +fi + if [ -n "${CONFIG_BUILDTIME_EXTABLE_SORT}" ]; then info SORTEX vmlinux sortextable vmlinux