From: Namhyung Kim <namhyung@kernel.org>
To: Zhan Xusheng <zhanxusheng1024@gmail.com>
Cc: Ian Rogers <irogers@google.com>,
Zhan Xusheng <zhanxusheng@xiaomi.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Changbin Du <changbin.du@huawei.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] perf symbols: Don't apply the symfs layout to synthesised paths
Date: Tue, 15 Sep 2026 22:33:42 -0700 [thread overview]
Message-ID: <aqoqNqr0DHaO5g-t@google.com> (raw)
In-Reply-To: <20260916033648.500387-1-zhanxusheng@xiaomi.com>
Hello,
On Wed, Sep 16, 2026 at 11:36:47AM +0800, Zhan Xusheng wrote:
> On Tue, Sep 15, 2026 at 01:31:16PM -0700, Ian Rogers wrote:
> > In those before and after examples, the 'before' case seems to better
> > match what the user is requesting on the command line, so I think I'm
> > misunderstanding something.
>
> Neither side is the flat layout. The changelog showed the prefixes and
> not the full paths they end up in, so there was nothing in it to see that
> from.
>
> For /usr/lib/x86_64-linux-gnu/libc.so.6 the base name is libc.so.6.debug,
> so the flat lookup is /s/libc.so.6.debug. With --symfs /s,flat, the
> FEDORA_DEBUGINFO path actually tried is
>
> before /s/debug/usr/lib/x86_64-linux-gnu/libc.so.6.debug
> after /s//usr/lib/debug/usr/lib/x86_64-linux-gnu/libc.so.6.debug
For the original purpose of the flat symfs, I believe it should be
/s/libc.so.6.debug
>
> Both carry /usr/lib/x86_64-linux-gnu/libc.so.6 whole. perf_basename()
> only ever saw the prefix, because the DSO path arrives after it:
>
> len = __symbol__join_symfs(filename, size, "/usr/lib/debug");
> snprintf(filename + len, size - len, "%s.debug", dso__long_name(dso));
>
> Before is shorter in its first component, which is what makes it read as
> flatter, but the layout that was asked for is on neither side.
>
> BUILDID_DEBUGINFO is the one I would not try to defend as intended. Its
> prefix is "/usr/lib/debug/.build-id/", and perf_basename() of a path
> ending in '/' is "", so the prefix does not become shorter, it disappears:
>
> before <symfs>/ab/cdef...ff.debug
> after <symfs>//usr/lib/debug/.build-id/ab/cdef...ff.debug
This is somewhat confusing as it uses the first 2 character as a
directory name. But I believe this should be
/s/abcdef..ff.debug
>
> Where the argument is the file being looked for, the option does what it
> says and the patch changes nothing:
>
> __symbol__join_symfs(filename, size, dso__long_name(dso));
>
> /s/libc.so.6, /s/ld-linux-x86-64.so.2, /s/sleep.
These look fine.
>
> So the patch is narrow: it keeps a flat request from rewriting perf's own
> fixed prefixes. It does not make flat find distro debuginfo -- for a user
> whose debug files really are flat under <symfs>, both columns miss. That
> needs the base name taken from the composed filename instead of the
> prefix, which is a different change and not a Fixes:. I can write that
> one instead if you would rather have it.
>
> 8 paths change across those 4 sites and 13 are untouched; hierarchy is
> identical between the two builds at all 21. The doubled slash comes from
> path__join(), it predates this and shows up in untouched paths too.
>
> The v2 changelog also said four paths differ while listing four call
> sites; it is eight paths. That did not help.
Can you please change the symfs join function just to use the basename
so that it can really have the flat directory structure inside symfs?
Thanks,
Namhyung
prev parent reply other threads:[~2026-09-16 5:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 9:46 Zhan Xusheng
2026-09-15 20:31 ` Ian Rogers
2026-09-16 3:36 ` Zhan Xusheng
2026-09-16 5:33 ` Namhyung Kim [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=aqoqNqr0DHaO5g-t@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=changbin.du@huawei.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=zhanxusheng1024@gmail.com \
--cc=zhanxusheng@xiaomi.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
all inboxes | Powered by JetHome®