All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: andrii.nakryiko@gmail.com
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, kernel-team@fb.com,
	Andrii Nakryiko <andriin@fb.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@fb.com>, Yonghong Song <yhs@fb.com>,
	Martin KaFai Lau <kafai@fb.com>
Subject: Re: [PATCH bpf-next] kbuild: add ability to generate BTF type info for vmlinux
Date: Wed, 3 Apr 2019 10:46:19 +0200	[thread overview]
Message-ID: <20190403084619.GA23855@krava> (raw)
In-Reply-To: <20190402164950.429597-1-andrii.nakryiko@gmail.com>

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
> 

  parent reply	other threads:[~2019-04-03  8:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02 16:49 [PATCH bpf-next] kbuild: add ability to generate BTF type info for vmlinux andrii.nakryiko
2019-04-02 17:40 ` David Miller
2019-04-02 23:00 ` Daniel Borkmann
2019-04-03  8:46 ` Jiri Olsa [this message]
2019-04-03  9:04   ` Daniel Borkmann
2019-04-03  9:12     ` Jiri Olsa
2019-04-03  9:21       ` Daniel Borkmann
2019-04-03 12:05       ` Arnaldo Carvalho de Melo
2019-04-04  0:40       ` Arnaldo Carvalho de Melo
2019-04-04  8:47         ` Jiri Olsa
  -- strict thread matches above, loose matches on Subject: below --
2019-03-15 20:17 Andrii Nakryiko
2019-03-25 15:59 ` Alexei Starovoitov
2019-03-27  1:24   ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190403084619.GA23855@krava \
    --to=jolsa@redhat.com \
    --cc=acme@redhat.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kafai@fb.com \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=yamada.masahiro@socionext.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.