linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Thomas Richter <tmricht@linux.ibm.com>,
	"linux-perf-use." <linux-perf-users@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Sven Schnelle <svens@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Stefan Liebler <stli@linux.ibm.com>
Subject: Re: Part 2: perf test case probe libc fails with latest Fedora34 glibc update
Date: Fri, 2 Jul 2021 09:41:37 +0900	[thread overview]
Message-ID: <20210702094137.8e4e8c14ff7956749bbbd38c@kernel.org> (raw)
In-Reply-To: <20210701010208.6c5129241ab490bc6a6b3197@kernel.org>

Hi,

On Thu, 1 Jul 2021 01:02:08 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> Hi Thomas,
> 
> OK, I finally found 2 root causes for this issue.
> 
> 1. debuginfo__new() forgot to call dso__load(). Thus, the dso is
> just initialized, but doesn't load the build-id. Then the build-id
> based debuginfo file is not searched. It must use map instead of dso.

I made a fix for this issue using dso__set_build_id() because
using dso__load() which loads symbols just for build-id seems sledgehammer.
So now I can see the perf probe opens build-id based debuginfo correctly.

However, this will not fix your issue because;

> 2. Not sure why, but /usr/lib64/libc-2.33.so is shown as "not stripped"
> binary. Then the elfutils is fooled by the information and open it
> as a debuginfo file. I think probe-finder.c also need to check the
> given file has DIE tree (debuginfo) or not by itself.

this part is not correct. perf-probe is using elfutils, which has
its own debuginfo search algorithm. Thus with or without the above
fix, perf-probe finally opens the correct debuginfo.
(from this reason, I can not show what has been fixed by the command
 output in commit message without debug print.)

And with decoding the debuginfo, I finally understand what was wrong.
The problem is that the "inet_pton" is a dynamic symbol, which does *NOT*
exist in the debuginfo. There is "__inet_pton" instead of "inet_pton".

-----
/* Like __inet_pton_length, but use strlen (SRC) as the length of
   SRC.  */
int
__inet_pton (int af, const char *src, void *dst)
{
  return __inet_pton_length (af, src, strlen (src), dst);
}
libc_hidden_def (__inet_pton)
weak_alias (__inet_pton, inet_pton)
libc_hidden_weak (inet_pton)
-----

Thus, if you pass the __inet_pton to perf-probe, it works.

-----
$ ./perf probe -x /lib64/libc.so.6 -L __inet_pton
<__inet_pton@/usr/src/debug/glibc-2.33-18.fc34.aarch64/resolv/inet_pton.c:0>
      0  __inet_pton (int af, const char *src, void *dst)
         {
           return __inet_pton_length (af, src, strlen (src), dst);
         }
-----

And -F (--functions) doesn't work yet.
-----
./perf probe  -x /usr/lib64/libc-2.33.so -F
@plt
@plt
calloc@plt
free@plt
malloc@plt
memalign@plt
realloc@plt
-----

I think we should remove @plt, and decode ".dynsym" in addition to ".symtab"
by map object for this issue at first. Then we may be able to get the address
of "inet_pton" from map.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

  reply	other threads:[~2021-07-02  0:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 14:21 Thomas Richter
2021-06-25 10:34 ` Jiri Olsa
2021-06-25 10:57   ` Thomas Richter
2021-06-25 10:43 ` Part 2: " Thomas Richter
2021-06-29  5:02   ` Masami Hiramatsu
2021-06-29  6:42     ` Thomas Richter
2021-06-29 14:06       ` Masami Hiramatsu
2021-06-30 16:02       ` Masami Hiramatsu
2021-07-02  0:41         ` Masami Hiramatsu [this message]
2021-06-29  7:21     ` perf test case probe libc fails with latest Fedora34 glibc update, more info Thomas Richter
2021-06-29 14:01       ` Masami Hiramatsu

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=20210702094137.8e4e8c14ff7956749bbbd38c@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=acme@kernel.org \
    --cc=hca@linux.ibm.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=stli@linux.ibm.com \
    --cc=svens@linux.ibm.com \
    --cc=tmricht@linux.ibm.com \
    --subject='Re: Part 2: perf test case probe libc fails with latest Fedora34 glibc update' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).