From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
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: [PATCH 2/3] btf_encoder: Change functions check due to broken dwarf
Date: Wed, 28 Oct 2020 16:50:49 +0100 [thread overview]
Message-ID: <20201028155049.GP2900849@krava> (raw)
In-Reply-To: <CAEf4BzZZ6abHMB4Y2wHF+0vGVqJ_UtMnjDfSscVXbHUZcfEGtg@mail.gmail.com>
On Tue, Oct 27, 2020 at 04:20:10PM -0700, Andrii Nakryiko wrote:
> On Mon, Oct 26, 2020 at 5:07 PM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > We need to generate just single BTF instance for the
> > function, while DWARF data contains multiple instances
> > of DW_TAG_subprogram tag.
> >
> > Unfortunately we can no longer rely on DW_AT_declaration
> > tag (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060)
> >
> > Instead we apply following checks:
> > - argument names are defined for the function
> > - there's symbol and address defined for the function
> > - function is generated only once
> >
> > They might be slightly superfluous together, but it's
> > better to be ready for another DWARF mishap.
> >
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > btf_encoder.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++++-
> > elf_symtab.h | 8 ++++
> > 2 files changed, 109 insertions(+), 1 deletion(-)
> >
> > diff --git a/btf_encoder.c b/btf_encoder.c
> > index 2dd26c904039..99b9abe36993 100644
> > --- a/btf_encoder.c
> > +++ b/btf_encoder.c
> > @@ -26,6 +26,62 @@
> > */
> > #define KSYM_NAME_LEN 128
> >
> > +struct elf_function {
> > + const char *name;
> > + bool generated;
> > +};
> > +
> > +static struct elf_function *functions;
> > +static int functions_alloc;
> > +static int functions_cnt;
> > +
> > +static int functions_cmp(const void *_a, const void *_b)
> > +{
> > + const struct elf_function *a = _a;
> > + const struct elf_function *b = _b;
> > +
> > + return strcmp(a->name, b->name);
> > +}
> > +
> > +static void delete_functions(void)
> > +{
> > + free(functions);
> > + functions_alloc = functions_cnt = 0;
> > +}
> > +
> > +static int config_function(struct btf_elf *btfe, GElf_Sym *sym)
> > +{
> > + if (!elf_sym__is_function(sym))
> > + return 0;
> > + if (!elf_sym__value(sym))
> > + return 0;
> > +
> > + if (functions_cnt == functions_alloc) {
> > + functions_alloc += 5000;
>
> maybe just do a conventional exponential size increase? Not
> necessarily * 2, could be (* 3 / 2) or (* 4 / 3), libbpf uses such
> approach.
ok, will change
>
> > + functions = realloc(functions, functions_alloc * sizeof(*functions));
> > + if (!functions)
> > + return -1;
> > + }
> > +
> > + functions[functions_cnt].name = elf_sym__name(sym, btfe->symtab);
> > + functions_cnt++;
> > + return 0;
> > +}
> > +
>
> [...]
>
> > diff --git a/elf_symtab.h b/elf_symtab.h
> > index 359add69c8ab..094ec4683d01 100644
> > --- a/elf_symtab.h
> > +++ b/elf_symtab.h
> > @@ -63,6 +63,14 @@ static inline uint64_t elf_sym__value(const GElf_Sym *sym)
> > return sym->st_value;
> > }
> >
> > +static inline int elf_sym__is_function(const GElf_Sym *sym)
> > +{
> > + return (elf_sym__type(sym) == STT_FUNC ||
> > + elf_sym__type(sym) == STT_GNU_IFUNC) &&
>
> Why do we need to collect STT_GNU_IFUNC? That is some PLT special
> magic, does the kernel use that? Even if it does, are we even able to
> attach to that? Could that remove some of the assembly functions?
I missed that when I copied that function from perf ;-) I'll check
jirka
>
> > + sym->st_name != 0 &&
> > + sym->st_shndx != SHN_UNDEF;
> > +}
> > +
> > static inline bool elf_sym__is_local_function(const GElf_Sym *sym)
> > {
> > return elf_sym__type(sym) == STT_FUNC &&
> > --
> > 2.26.2
> >
>
next prev parent reply other threads:[~2020-10-28 21:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 22:36 [RFC 0/3] pahole: Workaround dwarf bug for function encoding Jiri Olsa
2020-10-26 22:36 ` [PATCH 1/3] btf_encoder: Move find_all_percpu_vars in generic config function Jiri Olsa
2020-10-27 23:12 ` Andrii Nakryiko
2020-10-27 23:54 ` Hao Luo
2020-10-28 15:51 ` Jiri Olsa
2020-10-26 22:36 ` [PATCH 2/3] btf_encoder: Change functions check due to broken dwarf Jiri Olsa
2020-10-27 23:20 ` Andrii Nakryiko
2020-10-28 15:50 ` Jiri Olsa [this message]
2020-10-26 22:36 ` [PATCH 3/3] btf_encoder: Include static functions to BTF data Jiri Olsa
2020-10-27 23:21 ` Andrii Nakryiko
2020-10-28 15:53 ` Jiri Olsa
2020-10-27 23:13 ` [RFC 0/3] pahole: Workaround dwarf bug for function encoding Andrii Nakryiko
2020-10-28 15:49 ` Jiri Olsa
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=20201028155049.GP2900849@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=fche@redhat.com \
--cc=haoluo@google.com \
--cc=jolsa@kernel.org \
--cc=mjw@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox