Re: [RFC 0/3] pahole: Workaround dwarf bug for function encoding

From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	dwarves@vger.kernel.org, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andriin@fb.com>, Yonghong Song <yhs@fb.com>,
	Hao Luo <haoluo@google.com>, "Frank Ch. Eigler" <fche@redhat.com>,
	Mark Wielaard <mjw@redhat.com>
Subject: Re: [RFC 0/3] pahole: Workaround dwarf bug for function encoding
Date: Tue, 27 Oct 2020 16:13:46 -0700	[thread overview]
Message-ID: <CAEf4Bzav_WF3duq4JYmaPvyUXdREkXJMPAb+ASUxAxq_mqXd5Q@mail.gmail.com> (raw)
In-Reply-To: <20201026223617.2868431-1-jolsa@kernel.org>

On Mon, Oct 26, 2020 at 5:07 PM Jiri Olsa <jolsa@kernel.org> wrote:
>
> hi,
> because of gcc bug [1] we can no longer rely on DW_AT_declaration
> attribute to filter out declarations and end up with just
> one copy of the function in the BTF data.
>
> It seems this bug is not easy to fix, but regardless if the
> it's coming soon, it's probably good idea not to depend so
> much only on dwarf data and make some extra checks.
>
> Thus for function encoding we are now doing following checks:
>   - argument names are defined for the function
>   - there's symbol and address defined for the function
>   - function is generated only once
>
> These checks ensure that we encode function with defined
> symbol/address and argument names.
>
> I marked this post as RFC, because with this workaround in
> place we are also encoding assembly functions, which were
> not present when using the previous gcc version.
>
> Full functions diff to previous gcc working version:
>
>   http://people.redhat.com/~jolsa/functions.diff.txt
>
> I'm not sure this does not break some rule for functions in
> BTF data, becuse those assembly functions are not attachable
> by bpf trampolines, so I don't think there's any use for them.

What will happen if we do try to attach to those assembly functions?
Will there be some corruption or crash, or will it just fail and
return error cleanly? What we actually want in BTF is all the
functions that are attachable through BPF trampoline, which is all the
functions that ftrace subsystem can attach to, right? So how does
ftrace system know what can or cannot be attached to?

>
> thoughts?
> jirka
>
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060
> ---
> Jiri Olsa (3):
>       btf_encoder: Move find_all_percpu_vars in generic config function
>       btf_encoder: Change functions check due to broken dwarf
>       btf_encoder: Include static functions to BTF data
>
>  btf_encoder.c | 221 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------
>  elf_symtab.h  |   8 +++++
>  2 files changed, 170 insertions(+), 59 deletions(-)
>