All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jiri Slaby <jslaby@suse.cz>
Cc: jolsa@redhat.com, linux-kernel@vger.kernel.org,
	Namhyung Kim <namhyung@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>
Subject: Re: [PATCH v2] perf tools: Resolve symbols against debug file first
Date: Wed, 17 Feb 2021 09:51:10 -0300	[thread overview]
Message-ID: <YC0RPsH83ppYFsBF@kernel.org> (raw)
In-Reply-To: <20210217122125.26416-1-jslaby@suse.cz>

Em Wed, Feb 17, 2021 at 01:21:25PM +0100, Jiri Slaby escreveu:
> With LTO, there are symbols like these:
> /usr/lib/debug/usr/lib64/libantlr4-runtime.so.4.8-4.8-1.4.x86_64.debug
>  10305: 0000000000955fa4     0 NOTYPE  LOCAL  DEFAULT   29 Predicate.cpp.2bc410e7
> 
> This comes from a runtime/debug split done by the standard way:
> objcopy --only-keep-debug $runtime $debug
> objcopy --add-gnu-debuglink=$debugfn -R .comment -R .GCC.command.line --strip-all $runtime
> 
> perf currently cannot resolve such symbols (relicts of LTO), as section
> 29 exists only in the debug file (29 is .debug_info). And perf resolves
> symbols only against runtime file. This results in all symbols from such
> a library being unresolved:
>      0.38%  main2    libantlr4-runtime.so.4.8  [.] 0x00000000000671e0
> 
> So try resolving against the debug file first. And only if it fails (the
> section has NOBITS set), try runtime file. We can do this, as "objcopy
> --only-keep-debug" per documentation preserves all sections, but clears
> data of some of them (the runtime ones) and marks them as NOBITS.
> 
> The correct result is now:
>      0.38%  main2    libantlr4-runtime.so.4.8  [.] antlr4::IntStream::~IntStream
> 
> Note that these LTO symbols are properly skipped anyway as they belong
> neither to *text* nor to *data* (is_label && !elf_sec__filter(&shdr,
> secstrs) is true).
> 
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Acked-by: Namhyung Kim <namhyung@kernel.org>

Thanks, applied.

- Arnaldo

> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Jiri Olsa <jolsa@redhat.com>
> ---
> [v2] added a comment
> 
>  tools/perf/util/symbol-elf.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> index f3577f7d72fe..ecc05aa8399d 100644
> --- a/tools/perf/util/symbol-elf.c
> +++ b/tools/perf/util/symbol-elf.c
> @@ -1226,12 +1226,26 @@ int dso__load_sym(struct dso *dso, struct map *map, struct symsrc *syms_ss,
>  		if (sym.st_shndx == SHN_ABS)
>  			continue;
>  
> -		sec = elf_getscn(runtime_ss->elf, sym.st_shndx);
> +		sec = elf_getscn(syms_ss->elf, sym.st_shndx);
>  		if (!sec)
>  			goto out_elf_end;
>  
>  		gelf_getshdr(sec, &shdr);
>  
> +		/*
> +		 * We have to fallback to runtime when syms' section header has
> +		 * NOBITS set. NOBITS results in file offset (sh_offset) not
> +		 * being incremented. So sh_offset used below has different
> +		 * values for syms (invalid) and runtime (valid).
> +		 */
> +		if (shdr.sh_type == SHT_NOBITS) {
> +			sec = elf_getscn(runtime_ss->elf, sym.st_shndx);
> +			if (!sec)
> +				goto out_elf_end;
> +
> +			gelf_getshdr(sec, &shdr);
> +		}
> +
>  		if (is_label && !elf_sec__filter(&shdr, secstrs))
>  			continue;
>  
> -- 
> 2.30.1
> 

-- 

- Arnaldo

      reply	other threads:[~2021-02-17 12:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 12:21 [PATCH v2] perf tools: Resolve symbols against debug file first Jiri Slaby
2021-02-17 12:51 ` Arnaldo Carvalho de Melo [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=YC0RPsH83ppYFsBF@kernel.org \
    --to=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.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.