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/2] btf_encoder: Change functions check due to broken dwarf
Date: Tue, 3 Nov 2020 20:34:14 +0100 [thread overview]
Message-ID: <20201103193414.GK3597846@krava> (raw)
In-Reply-To: <CAEf4BzbMOzAdsyMT736idoGnJ1RuxRa5y9wf-egh+LKz406m1g@mail.gmail.com>
On Tue, Nov 03, 2020 at 11:23:33AM -0800, Andrii Nakryiko wrote:
SNIP
> > > on what's missing and why it shouldn't be missing?
> >
> > yes, it's just a hack, we should do something more
> > robust as I mentioned above
> >
> > it just allowed me to use iterators finaly ;-)
>
> sure, I get it, I was just trying to understand why there is such a
> problem in the first place. Turns out we need FUNCs not just for
> fentry/fexit and similar, but also for bpf_iter, which is an entirely
> different use case (similar to raw_tp, but raw_tp is using typedef ->
> func_proto approach).
>
> So I don't know, we might as well just not do mcount checks?.. As an
> alternative, but it's not great as well.
how about moving all such functions to separate new .init.XXX section,
and pahole would make one extr acheck for that.. and it still gets freed
jirka
next prev parent reply other threads:[~2020-11-03 19:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-31 22:31 [PATCHv2 0/2] pahole: Workaround dwarf bug for function encoding Jiri Olsa
2020-10-31 22:31 ` [PATCH 1/2] btf_encoder: Move find_all_percpu_vars in generic collect_symbols Jiri Olsa
2020-11-02 18:29 ` Hao Luo
2020-11-03 17:31 ` Arnaldo Carvalho de Melo
2020-10-31 22:31 ` [PATCH 2/2] btf_encoder: Change functions check due to broken dwarf Jiri Olsa
2020-11-02 21:59 ` Jiri Olsa
2020-11-02 22:56 ` Jiri Olsa
2020-11-03 18:58 ` Andrii Nakryiko
2020-11-03 19:05 ` Jiri Olsa
2020-11-03 19:23 ` Andrii Nakryiko
2020-11-03 19:34 ` Jiri Olsa [this message]
2020-11-03 20:27 ` Yonghong Song
2020-11-03 23:18 ` Jiri Olsa
2020-11-03 18:55 ` Andrii Nakryiko
2020-11-03 23:22 ` 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=20201103193414.GK3597846@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;
as well as URLs for NNTP newsgroup(s).