mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Allison Randal <allison@lohutok.net>,
	Hendrik Brueckner <brueckner@linux.vnet.ibm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Enrico Weigelt <info@metux.net>,
	John Garry <john.garry@huawei.com>, Jiri Olsa <jolsa@redhat.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Mike Leach <mike.leach@linaro.org>,
	Ingo Molnar <mingo@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Thomas Richter <tmricht@linux.vnet.ibm.com>
Subject: Re: [PATCH v2] perf symbols: Consolidate symbol fixup issue
Date: Thu, 05 Mar 2020 18:05:25 +0530	[thread overview]
Message-ID: <1583411597.adgw1518ss.naveen@linux.ibm.com> (raw)
In-Reply-To: <20200305120738.GA31049@leoy-ThinkPad-X240s>

Leo Yan wrote:
> Hi Naveen,
> 
> On Thu, Mar 05, 2020 at 04:32:30PM +0530, Naveen N. Rao wrote:
>> Leo Yan wrote:
<snip>
>> > In the common elf__needs_adjust_symbols(), it checks elf header and 
>> > if
>> > the machine type is one of Arm64/ppc/ppc64, it checks extra condition
>> > for 'ET_DYN'.  Finally, the Arm64 DSO can be parsed properly with x86's
>> > perf tool.
>> > 
>> > Before:
>> > 
>> >   # perf script
>> >   main  3258          1          branches:                 0 [unknown] ([unknown]) => ffff800010c4665c [unknown] ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c46670 [unknown] ([kernel.kallsyms]) => ffff800010c4eaec [unknown] ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c4eaec [unknown] ([kernel.kallsyms]) => ffff800010c4eb00 [unknown] ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c4eb08 [unknown] ([kernel.kallsyms]) => ffff800010c4e780 [unknown] ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c4e7a0 [unknown] ([kernel.kallsyms]) => ffff800010c4eeac [unknown] ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c4eebc [unknown] ([kernel.kallsyms]) => ffff800010c4ed80 [unknown] ([kernel.kallsyms])
>> > 
>> > After:
>> > 
>> >   # perf script
>> >   main  3258          1          branches:                 0 [unknown] ([unknown]) => ffff800010c4665c coresight_timeout+0x54 ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c46670 coresight_timeout+0x68 ([kernel.kallsyms]) => ffff800010c4eaec etm4_enable_hw+0x3cc ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c4eaec etm4_enable_hw+0x3cc ([kernel.kallsyms]) => ffff800010c4eb00 etm4_enable_hw+0x3e0 ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c4eb08 etm4_enable_hw+0x3e8 ([kernel.kallsyms]) => ffff800010c4e780 etm4_enable_hw+0x60 ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c4e7a0 etm4_enable_hw+0x80 ([kernel.kallsyms]) => ffff800010c4eeac etm4_enable+0x2d4 ([kernel.kallsyms])
>> >   main  3258          1          branches:  ffff800010c4eebc etm4_enable+0x2e4 ([kernel.kallsyms]) => ffff800010c4ed80 etm4_enable+0x1a8 ([kernel.kallsyms])
>> > 
>> 
>> I am not able to reproduce this since powerpc64 kernels are not being built
>> as ET_EXEC anymore.
> 
> Thanks for reviewing!
> 
> Based on the context, I think you mean powerpc64 kernels are not being
> built as ET_DYN anymore (and now change to ET_EXEC).

D'uh, indeed, sorry!

> 
>> > v2: Fixed Arm64 and powerpc native building.
>> > 
>> > Reported-by: Mike Leach <mike.leach@linaro.org>
>> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> > ---
>> >  tools/perf/arch/arm64/util/Build            |  1 -
>> >  tools/perf/arch/arm64/util/sym-handling.c   | 19 -------------------
>> >  tools/perf/arch/powerpc/util/Build          |  1 -
>> >  tools/perf/arch/powerpc/util/sym-handling.c | 10 ----------
>> >  tools/perf/util/symbol-elf.c                |  8 +++++++-
>> >  5 files changed, 7 insertions(+), 32 deletions(-)
>> >  delete mode 100644 tools/perf/arch/arm64/util/sym-handling.c
>> > 
<snip>
>> > diff --git a/tools/perf/util/symbol-elf.c 
>> > b/tools/perf/util/symbol-elf.c
>> > index 1965aefccb02..ee788ac67415 100644
>> > --- a/tools/perf/util/symbol-elf.c
>> > +++ b/tools/perf/util/symbol-elf.c
>> > @@ -704,8 +704,14 @@ void symsrc__destroy(struct symsrc *ss)
>> >  	close(ss->fd);
>> >  }
>> > 
>> > -bool __weak elf__needs_adjust_symbols(GElf_Ehdr ehdr)
>> > +bool elf__needs_adjust_symbols(GElf_Ehdr ehdr)
>> >  {
>> > +	if (ehdr.e_machine == EM_AARCH64 ||
>> > +	    ehdr.e_machine == EM_PPC ||
>> > +	    ehdr.e_machine == EM_PPC64)
>> > +		return ehdr.e_type == ET_EXEC || ehdr.e_type == ET_REL ||
>> > +		       ehdr.e_type == ET_DYN;
>> > +
>> >  	return ehdr.e_type == ET_EXEC || ehdr.e_type == ET_REL;
>> 
>> Patch looks good to me. However:
> 
> Can I add your review tag?

Yes:
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>

> 
>> This is only used for checking kernel, so I wonder if we can simply include
>> check for ET_DYN across all architectures? This would only matter if there
>> are architectures building their kernel as ET_DYN that _don't_ want to
>> adjust symbols.
> 
> Seems only Arm64 enables the link option '-share' for LDFLAGS_vmlinux;
> I confirmed with below command:
> 
> $ find arch -name 'Makefile' -exec grep -n '\-share' {} + | grep vmlinux
> arch/arm64/Makefile:21:LDFLAGS_vmlinux          += -shared -Bsymbolic -z notext -z norelro \
> 
> Also reviewed the output for searching '\-share' for all Makefiles under
> 'arch' folder, many architectures use it for vdso but only Arm64 enables
> '-share' for vmlinux linkage.  If so, your suggestion is valid and we
> can simply include check for ET_DYN for all archs (and it's better to
> add comment for this).
> 
> I'd like to wait a bit for anyone has other ideas, and if no objection
> will send out new patch for this.

Sure, thanks for checking.


- Naveen


      reply	other threads:[~2020-03-05 12:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 11:04 Leo Yan
2020-03-05 11:02 ` Naveen N. Rao
2020-03-05 12:07   ` Leo Yan
2020-03-05 12:35     ` Naveen N. Rao [this message]

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=1583411597.adgw1518ss.naveen@linux.ibm.com \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=allison@lohutok.net \
    --cc=brueckner@linux.vnet.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=info@metux.net \
    --cc=john.garry@huawei.com \
    --cc=jolsa@redhat.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tmricht@linux.vnet.ibm.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

Powered by JetHome