From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
jolsa@kernel.org, irogers@google.com, namhyung@kernel.org,
linux-perf-users@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
maddy@linux.ibm.com, kjain@linux.ibm.com,
disgoel@linux.vnet.ibm.com
Subject: Re: [PATCH] tools/perf: Fix dso kernel load and symbol process to correctly map dso to its long_name, type and adjust_symbols
Date: Fri, 11 Aug 2023 10:46:57 -0300 [thread overview]
Message-ID: <ZNY70VuUn0e86bAD@kernel.org> (raw)
In-Reply-To: <f21cbbed-8e51-fae1-9e77-56b5d239bafd@intel.com>
Em Fri, Aug 11, 2023 at 12:49:35PM +0300, Adrian Hunter escreveu:
> On 11/08/23 08:15, Athira Rajeev wrote:
> > Test "object cocde reading" fails sometimes for kernel address
> > as below:
> >
> > Reading object code for memory address: 0xc000000000004c3c
> > File is: [kernel.kallsyms]
> > On file address is: 0x14c3c
> > dso__data_read_offset failed
> > test child finished with -1
> > ---- end ----
> > Object code reading: FAILED!
> >
> > Here the dso__data_read_offset fails for symbol address
> > 0xc000000000004c3c. This is because, the dso long_name here
> > is [kernel.kallsyms] and hence open_dso fails to open this
> > file. There is an incorrect dso to map handling here. The
> > key points here is:
> > - dso long_name is set to [kernel.kallsyms]. This file is
> > not present and hence returns error
> > - DSO binary type is set to DSO_BINARY_TYPE__NOT_FOUND
> > - dso adjust_symbols is set to zero
> >
> > In the end dso__data_read_offset() returns -1 and the address
> > 0x14c3c can not be resolved. Hence the test fails. But the
> > address actually maps to kernel dso
> >
> > # objdump -z -d --start-address=0xc000000000004c3c --stop-address=0xc000000000004cbc /home/athira/linux/vmlinux
> >
> > /home/athira/linux/vmlinux: file format elf64-powerpcle
> >
> > Disassembly of section .head.text:
> >
> > c000000000004c3c <exc_virt_0x4c00_system_call+0x3c>:
> > c000000000004c3c: a6 02 9b 7d mfsrr1 r12
> > c000000000004c40: 78 13 42 7c mr r2,r2
> > c000000000004c44: 18 00 4d e9 ld r10,24(r13)
> > c000000000004c48: 60 c6 4a 61 ori r10,r10,50784
> > c000000000004c4c: a6 03 49 7d mtctr r10
> >
> > Fix the dso__process_kernel_symbol function to set the
> > binary_type and adjust_symbols. adjust_symbols is used by
> > function "map__rip_2objdump" which converts symbol start
> > address to objdump address. Also set the dso long_name during
> > dso__load_vmlinux function.
> >
> > Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
> > Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Thanks, applied.
- Arnaldo
> > ---
> > Note: Found similar discussion here in thread:
> > https://www.spinics.net/lists/linux-perf-users/msg06337.html
> > where Adrian proposed the fix, but looks like this was
> > not added to the perf. Hence addeed Suggested-by from Adrian.
> >
> > Additional to the fix proposed by Adrian, the patch also
> > adds setting of adjust_symbols which is needed for
> > map__rip_2objdump to convert symbol start to objdump address.
> >
> > tools/perf/util/symbol-elf.c | 2 ++
> > tools/perf/util/symbol.c | 15 ++++++++++-----
> > 2 files changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> > index 252d26a59e64..9e7eeaf616b8 100644
> > --- a/tools/perf/util/symbol-elf.c
> > +++ b/tools/perf/util/symbol-elf.c
> > @@ -1440,6 +1440,8 @@ static int dso__process_kernel_symbol(struct dso *dso, struct map *map,
> > curr_dso->kernel = dso->kernel;
> > curr_dso->long_name = dso->long_name;
> > curr_dso->long_name_len = dso->long_name_len;
> > + curr_dso->binary_type = dso->binary_type;
> > + curr_dso->adjust_symbols = dso->adjust_symbols;
> > curr_map = map__new2(start, curr_dso);
> > dso__put(curr_dso);
> > if (curr_map == NULL)
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index f849f9ef68e6..3f36675b7c8f 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -2204,15 +2204,20 @@ int dso__load_vmlinux(struct dso *dso, struct map *map,
> > if (symsrc__init(&ss, dso, symfs_vmlinux, symtab_type))
> > return -1;
> >
> > + /*
> > + * dso__load_sym() may copy 'dso' which will result in the copies having
> > + * an incorrect long name unless we set it here first.
> > + */
> > + dso__set_long_name(dso, vmlinux, vmlinux_allocated);
> > + if (dso->kernel == DSO_SPACE__KERNEL_GUEST)
> > + dso->binary_type = DSO_BINARY_TYPE__GUEST_VMLINUX;
> > + else
> > + dso->binary_type = DSO_BINARY_TYPE__VMLINUX;
> > +
> > err = dso__load_sym(dso, map, &ss, &ss, 0);
> > symsrc__destroy(&ss);
> >
> > if (err > 0) {
> > - if (dso->kernel == DSO_SPACE__KERNEL_GUEST)
> > - dso->binary_type = DSO_BINARY_TYPE__GUEST_VMLINUX;
> > - else
> > - dso->binary_type = DSO_BINARY_TYPE__VMLINUX;
> > - dso__set_long_name(dso, vmlinux, vmlinux_allocated);
> > dso__set_loaded(dso);
> > pr_debug("Using %s for symbols\n", symfs_vmlinux);
> > }
>
--
- Arnaldo
WARNING: multiple messages have this Message-ID (diff)
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: irogers@google.com, Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
kjain@linux.ibm.com, linux-perf-users@vger.kernel.org,
maddy@linux.ibm.com, jolsa@kernel.org, namhyung@kernel.org,
disgoel@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] tools/perf: Fix dso kernel load and symbol process to correctly map dso to its long_name, type and adjust_symbols
Date: Fri, 11 Aug 2023 10:46:57 -0300 [thread overview]
Message-ID: <ZNY70VuUn0e86bAD@kernel.org> (raw)
In-Reply-To: <f21cbbed-8e51-fae1-9e77-56b5d239bafd@intel.com>
Em Fri, Aug 11, 2023 at 12:49:35PM +0300, Adrian Hunter escreveu:
> On 11/08/23 08:15, Athira Rajeev wrote:
> > Test "object cocde reading" fails sometimes for kernel address
> > as below:
> >
> > Reading object code for memory address: 0xc000000000004c3c
> > File is: [kernel.kallsyms]
> > On file address is: 0x14c3c
> > dso__data_read_offset failed
> > test child finished with -1
> > ---- end ----
> > Object code reading: FAILED!
> >
> > Here the dso__data_read_offset fails for symbol address
> > 0xc000000000004c3c. This is because, the dso long_name here
> > is [kernel.kallsyms] and hence open_dso fails to open this
> > file. There is an incorrect dso to map handling here. The
> > key points here is:
> > - dso long_name is set to [kernel.kallsyms]. This file is
> > not present and hence returns error
> > - DSO binary type is set to DSO_BINARY_TYPE__NOT_FOUND
> > - dso adjust_symbols is set to zero
> >
> > In the end dso__data_read_offset() returns -1 and the address
> > 0x14c3c can not be resolved. Hence the test fails. But the
> > address actually maps to kernel dso
> >
> > # objdump -z -d --start-address=0xc000000000004c3c --stop-address=0xc000000000004cbc /home/athira/linux/vmlinux
> >
> > /home/athira/linux/vmlinux: file format elf64-powerpcle
> >
> > Disassembly of section .head.text:
> >
> > c000000000004c3c <exc_virt_0x4c00_system_call+0x3c>:
> > c000000000004c3c: a6 02 9b 7d mfsrr1 r12
> > c000000000004c40: 78 13 42 7c mr r2,r2
> > c000000000004c44: 18 00 4d e9 ld r10,24(r13)
> > c000000000004c48: 60 c6 4a 61 ori r10,r10,50784
> > c000000000004c4c: a6 03 49 7d mtctr r10
> >
> > Fix the dso__process_kernel_symbol function to set the
> > binary_type and adjust_symbols. adjust_symbols is used by
> > function "map__rip_2objdump" which converts symbol start
> > address to objdump address. Also set the dso long_name during
> > dso__load_vmlinux function.
> >
> > Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
> > Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Thanks, applied.
- Arnaldo
> > ---
> > Note: Found similar discussion here in thread:
> > https://www.spinics.net/lists/linux-perf-users/msg06337.html
> > where Adrian proposed the fix, but looks like this was
> > not added to the perf. Hence addeed Suggested-by from Adrian.
> >
> > Additional to the fix proposed by Adrian, the patch also
> > adds setting of adjust_symbols which is needed for
> > map__rip_2objdump to convert symbol start to objdump address.
> >
> > tools/perf/util/symbol-elf.c | 2 ++
> > tools/perf/util/symbol.c | 15 ++++++++++-----
> > 2 files changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> > index 252d26a59e64..9e7eeaf616b8 100644
> > --- a/tools/perf/util/symbol-elf.c
> > +++ b/tools/perf/util/symbol-elf.c
> > @@ -1440,6 +1440,8 @@ static int dso__process_kernel_symbol(struct dso *dso, struct map *map,
> > curr_dso->kernel = dso->kernel;
> > curr_dso->long_name = dso->long_name;
> > curr_dso->long_name_len = dso->long_name_len;
> > + curr_dso->binary_type = dso->binary_type;
> > + curr_dso->adjust_symbols = dso->adjust_symbols;
> > curr_map = map__new2(start, curr_dso);
> > dso__put(curr_dso);
> > if (curr_map == NULL)
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index f849f9ef68e6..3f36675b7c8f 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -2204,15 +2204,20 @@ int dso__load_vmlinux(struct dso *dso, struct map *map,
> > if (symsrc__init(&ss, dso, symfs_vmlinux, symtab_type))
> > return -1;
> >
> > + /*
> > + * dso__load_sym() may copy 'dso' which will result in the copies having
> > + * an incorrect long name unless we set it here first.
> > + */
> > + dso__set_long_name(dso, vmlinux, vmlinux_allocated);
> > + if (dso->kernel == DSO_SPACE__KERNEL_GUEST)
> > + dso->binary_type = DSO_BINARY_TYPE__GUEST_VMLINUX;
> > + else
> > + dso->binary_type = DSO_BINARY_TYPE__VMLINUX;
> > +
> > err = dso__load_sym(dso, map, &ss, &ss, 0);
> > symsrc__destroy(&ss);
> >
> > if (err > 0) {
> > - if (dso->kernel == DSO_SPACE__KERNEL_GUEST)
> > - dso->binary_type = DSO_BINARY_TYPE__GUEST_VMLINUX;
> > - else
> > - dso->binary_type = DSO_BINARY_TYPE__VMLINUX;
> > - dso__set_long_name(dso, vmlinux, vmlinux_allocated);
> > dso__set_loaded(dso);
> > pr_debug("Using %s for symbols\n", symfs_vmlinux);
> > }
>
--
- Arnaldo
next prev parent reply other threads:[~2023-08-11 13:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 5:15 [PATCH] tools/perf: Fix dso kernel load and symbol process to correctly map dso to its long_name, type and adjust_symbols Athira Rajeev
2023-08-11 5:15 ` Athira Rajeev
2023-08-11 9:49 ` Adrian Hunter
2023-08-11 9:49 ` Adrian Hunter
2023-08-11 13:46 ` Arnaldo Carvalho de Melo [this message]
2023-08-11 13:46 ` 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=ZNY70VuUn0e86bAD@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=disgoel@linux.vnet.ibm.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kjain@linux.ibm.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=namhyung@kernel.org \
/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.