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>
Subject: Re: [PATCHv3 0/2] btf_encoder: Fix functions BTF data generation
Date: Fri, 20 Nov 2020 17:13:24 -0800 [thread overview]
Message-ID: <CAEf4BzZ-0exZK7skcB_UjyatAx_R=hNqAXKVZ8EXgmSsHmthFg@mail.gmail.com> (raw)
In-Reply-To: <20201114223853.1010900-1-jolsa@kernel.org>
On Sat, Nov 14, 2020 at 2:39 PM Jiri Olsa <jolsa@kernel.org> wrote:
>
> hi,
> recent btf encoder's changes brakes BTF data for some gcc
> versions. The problem is that some functions can appear
> in dwarf data in some instances without arguments, while
> they are defined with some.
Hey Jiri,
So this approach with __start_mcount_loc/__stop_mcount_loc works for
vmlinux only, but it doesn't work for kernel modules. For kernel
modules there is a dedicated "__mcount_loc" section, but no
__start/__stop symbols. I'm working around for now by making sure
functions that I need are global, but it would be nice to have this
working for modules out of the box as well.
If you get a chance to fix this soon, that would be great. If not,
I'll try to get to this ASAP as well, because it would be nice to have
this in the same version of pahole that got static function BTFs for
vmlinux (if Arnaldo doesn't mind, of course).
>
> v3 changes:
> - move 'generated' flag set out of should_generate_function
> - rename should_generate_function to find_function
> - added ack
>
> v2 changes:
> - drop patch 3 logic and just change conditions
> based on Andrii's suggestion
> - drop patch 2
> - add ack for patch 1
>
> thanks,
> jirka
>
>
> ---
> Jiri Olsa (2):
> btf_encoder: Generate also .init functions
> btf_encoder: Fix function generation
>
> btf_encoder.c | 86 +++++++++++++++++++++-----------------------------------------------------------------
> 1 file changed, 21 insertions(+), 65 deletions(-)
>
next prev parent reply other threads:[~2020-11-21 1:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-14 22:38 [PATCHv3 0/2] btf_encoder: Fix functions BTF data generation Jiri Olsa
2020-11-14 22:38 ` [PATCH 1/2] btf_encoder: Generate also .init functions Jiri Olsa
2020-11-14 22:38 ` [PATCH 2/2] btf_encoder: Fix function generation Jiri Olsa
2020-11-21 1:13 ` Andrii Nakryiko [this message]
2020-11-22 22:56 ` [PATCHv3 0/2] btf_encoder: Fix functions BTF data generation Jiri Olsa
2020-11-23 0:25 ` Andrii Nakryiko
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='CAEf4BzZ-0exZK7skcB_UjyatAx_R=hNqAXKVZ8EXgmSsHmthFg@mail.gmail.com' \
--to=andrii.nakryiko@gmail.com \
--cc=acme@kernel.org \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=haoluo@google.com \
--cc=jolsa@kernel.org \
--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).