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>
Subject: Re: [PATCH 2/3] btf_encoder: Use address size based on ELF's class
Date: Fri, 4 Dec 2020 00:37:50 +0100 [thread overview]
Message-ID: <20201203233750.GG3613628@krava> (raw)
In-Reply-To: <CAEf4BzbdB4DUJ2BKVsVdpcZHunNxb_6FvAWOFt_be=81Jyxmnw@mail.gmail.com>
On Thu, Dec 03, 2020 at 03:22:18PM -0800, Andrii Nakryiko wrote:
> On Thu, Dec 3, 2020 at 2:08 PM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > We can't assume the address size is always size of unsigned
> > long, we have to use directly the ELF's address size.
> >
> > Changing addrs array to __u64 and convert 32 bit address
> > values when copying from ELF section.
> >
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
>
> It looks ok to me, but I didn't expect that changes would be so
> numerous... Makes me wonder if pahole ever supported working with ELF
> files of different bitness. I'll defer to Arnaldo to make a call on
> whether this is necessary.
so to test this I built 32bit vmlinux and used 64bit pahole
to generate BTF data on both vmlinux and modules, which I
thought was valid use case
jirka
>
> > btf_encoder.c | 24 +++++++++++++++++-------
> > 1 file changed, 17 insertions(+), 7 deletions(-)
> >
>
> [...]
>
next prev parent reply other threads:[~2020-12-03 23:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 22:06 [PATCHv2 0/3] btf_encoder: Detect kernel modules Jiri Olsa
2020-12-03 22:06 ` [PATCH 1/3] btf_encoder: Factor filter_functions function Jiri Olsa
2020-12-03 23:20 ` Andrii Nakryiko
2020-12-03 22:06 ` [PATCH 2/3] btf_encoder: Use address size based on ELF's class Jiri Olsa
2020-12-03 23:22 ` Andrii Nakryiko
2020-12-03 23:37 ` Jiri Olsa [this message]
2020-12-07 15:45 ` Arnaldo Carvalho de Melo
2020-12-03 22:06 ` [PATCH 3/3] btf_encoder: Detect kernel module ftrace addresses Jiri Olsa
2020-12-03 23:23 ` Andrii Nakryiko
2020-12-07 15:54 ` Arnaldo Carvalho de Melo
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=20201203233750.GG3613628@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=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 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.