All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Jiri Olsa <jolsa@redhat.com>
Cc: andrii.nakryiko@gmail.com, 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>,
	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 11:21:06 +0200	[thread overview]
Message-ID: <f6c63645-48b9-6cb8-2310-d3cf65b5e480@iogearbox.net> (raw)
In-Reply-To: <20190403091258.GA24875@krava>

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.

  reply	other threads:[~2019-04-03  9:21 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
2019-04-03  9:04   ` Daniel Borkmann
2019-04-03  9:12     ` Jiri Olsa
2019-04-03  9:21       ` Daniel Borkmann [this message]
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=f6c63645-48b9-6cb8-2310-d3cf65b5e480@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=acme@redhat.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=jolsa@redhat.com \
    --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.