All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>, Nick Clifton <nickc@redhat.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Michael Petlan <mpetlan@redhat.com>,
	Masami Hiramatsu <mhiramat@kernel.org>
Subject: [PATCH] perf tools: Filter out hidden symbols from labels
Date: Mon, 28 Jan 2019 14:35:26 +0100	[thread overview]
Message-ID: <20190128133526.GD15461@krava> (raw)
In-Reply-To: <20190115173838.GB31411@krava>

On Tue, Jan 15, 2019 at 06:38:38PM +0100, Jiri Olsa wrote:
> On Tue, Jan 15, 2019 at 04:13:16PM +0000, Nick Clifton wrote:
> > Hi Jiri,
> > 
> > > When perf is built with annobin plugin (RHEL8 build) extra symbols
> > > are added to its binary:
> > 
> >   A bit of background for those wondering why annobin is creating
> >   these symbols:  Annobin is a plugin for gcc that records data 
> >   about how object file were built.  It is specifically designed 
> >   to be able to cope with files that are built using multiple
> >   different sets of optimization options.  (Eg because of #pragma
> >   directives or function specific optimization attributes).  It
> >   generates notes to cover each compiled region of code, and it
> >   needs the symbols in order to be able to determine exactly which
> >   areas in a linked binary were compiled with which options.
> > 
> >   In the course of developing this plugin I encountered various
> >   problems with tools not expecting to find extra symbols in a
> >   binary.  Hence I made the symbols local, hidden and with no type.
> >   It was the best I could do to say "ignore these symbols - they
> >   are not meant to be seen by anyone but annobin".
> > 
> > 
> > > +		elf_sym__visibility(sym) != STV_HIDDEN;
> > 
> >   Just to be awkward, if you are going to ignore STV_HIDDEN 
> >   symbols then you should probably also ignore STV_INTERNAL ones
> >   as well...  Annobin does not generate them, but you never know,
> >   one day some other tool might create some.
> 
> sounds good, thanks

there were no objections for rfc, sending patch

thanks,
jirka


---
When perf is built with annobin plugin (RHEL8 build) extra symbols
are added to its binary:

  # nm perf | grep annobin | head -10
  0000000000241100 t .annobin_annotate.c
  0000000000326490 t .annobin_annotate.c
  0000000000249255 t .annobin_annotate.c_end
  00000000003283a8 t .annobin_annotate.c_end
  00000000001bce18 t .annobin_annotate.c_end.hot
  00000000001bce18 t .annobin_annotate.c_end.hot
  00000000001bc3e2 t .annobin_annotate.c_end.unlikely
  00000000001bc400 t .annobin_annotate.c_end.unlikely
  00000000001bce18 t .annobin_annotate.c.hot
  00000000001bce18 t .annobin_annotate.c.hot
  ...

those symbols have no use for report or annotation and should be skipped.
Moreover they interfere with dwarf unwind test on ppc arch, where they
are mixed with checked symbols and test fails:

  # perf test dwarf -v
  59: Test dwarf unwind                                     :
  --- start ---
  test child forked, pid 8515
  unwind: .annobin_dwarf_unwind.c:ip = 0x10dba40dc (0x2740dc)
  ...
  got: .annobin_dwarf_unwind.c 0x10dba40dc, expecting test__arch_unwind_sample
  unwind: failed with 'no error'

The annobin symbols are defined as NOTYPE/LOCAL/HIDDEN:

  # readelf -s ./perf | grep annobin | head -1
    40: 00000000001bce4f     0 NOTYPE  LOCAL  HIDDEN    13 .annobin_init.c

They can still pass the check for the label symbol. Adding
check for HIDDEN and INTERNAL (as suggested by Nick below)
visibility and filter out such symbols.

>   Just to be awkward, if you are going to ignore STV_HIDDEN
>   symbols then you should probably also ignore STV_INTERNAL ones
>   as well...  Annobin does not generate them, but you never know,
>   one day some other tool might create some.

Link: http://lkml.kernel.org/n/tip-4yuna6qhhg0df3q147cjdyuu@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 tools/perf/util/symbol-elf.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 66a84d5846c8..03cb8c6d620a 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -87,6 +87,11 @@ static inline uint8_t elf_sym__type(const GElf_Sym *sym)
 	return GELF_ST_TYPE(sym->st_info);
 }
 
+static inline uint8_t elf_sym__visibility(const GElf_Sym *sym)
+{
+	return GELF_ST_VISIBILITY(sym->st_other);
+}
+
 #ifndef STT_GNU_IFUNC
 #define STT_GNU_IFUNC 10
 #endif
@@ -111,7 +116,9 @@ static inline int elf_sym__is_label(const GElf_Sym *sym)
 	return elf_sym__type(sym) == STT_NOTYPE &&
 		sym->st_name != 0 &&
 		sym->st_shndx != SHN_UNDEF &&
-		sym->st_shndx != SHN_ABS;
+		sym->st_shndx != SHN_ABS &&
+		elf_sym__visibility(sym) != STV_HIDDEN &&
+		elf_sym__visibility(sym) != STV_INTERNAL;
 }
 
 static bool elf_sym__filter(GElf_Sym *sym)
-- 
2.17.2


  reply	other threads:[~2019-01-28 13:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15 13:53 [RFC] perf tools: Filter out hidden symbols from labels Jiri Olsa
2019-01-15 16:13 ` Nick Clifton
2019-01-15 16:35   ` Arnaldo Carvalho de Melo
2019-01-16  4:37     ` Namhyung Kim
2019-01-16 11:38       ` Nick Clifton
2019-01-16 13:31         ` Arnaldo Carvalho de Melo
2019-01-16 15:47           ` Nick Clifton
2019-01-16 16:04             ` Arnaldo Carvalho de Melo
2019-01-17 10:25               ` Nick Clifton
2019-01-17 13:26                 ` Arnaldo Carvalho de Melo
2019-01-15 17:38   ` [RFCv2] " Jiri Olsa
2019-01-28 13:35     ` Jiri Olsa [this message]
2019-01-29  9:07       ` [PATCH] " Arnaldo Carvalho de Melo
2019-01-29 11:25         ` Nick Clifton
2019-01-29 11:39           ` Arnaldo Carvalho de Melo
2019-01-29 12:57             ` Nick Clifton
2019-01-29 12:58             ` Nick Clifton
2019-02-04 14:45       ` Arnaldo Carvalho de Melo
2019-02-09 12:22       ` [tip:perf/urgent] perf symbols: " tip-bot for 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=20190128133526.GD15461@krava \
    --to=jolsa@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nickc@redhat.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.