linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Haoze Xie <royenheart@gmail.com>
To: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>,
	vmolnaro@redhat.com, peterz@infradead.org, mingo@redhat.com,
	acme@kernel.org, mark.rutland@arm.com,
	alexander.shishkin@linux.intel.com, jolsa@kernel.org,
	irogers@google.com, adrian.hunter@intel.com,
	kan.liang@linux.intel.com, linux-perf-users@vger.kernel.org,
	linux-kernel@vger.kernel.org, Yuan Tan <tanyuan@tinylab.org>
Subject: Re: [PATCH 1/1] perf archive: unpack to correct dir given by perf
Date: Wed, 24 Jul 2024 01:26:14 +0800	[thread overview]
Message-ID: <85253bf0-7222-4abb-a583-6c55f949e6bd@gmail.com> (raw)
In-Reply-To: <alpine.LRH.2.20.2407161424070.11376@Diego>



在 2024/7/16 20:29, Michael Petlan 写道:
> On Tue, 16 Jul 2024, royenheart wrote:
>> On 2024/7/12 12:35, Namhyung Kim wrote:
>>> Hello,
>>>
>>> On Mon, Jul 08, 2024 at 02:04:31AM +0800, Haoze Xie wrote:
>>>> In perf-archive.sh, the code segment that defines 'PERF_BUILDID_DIR' is
>>>> advanced before 'unpack' operation for subsequent use, followed by a
>>>> 'mkdir' operation to ensure that the dir exists. Symbols in 'unpack' will
>>>> be extracted to correct dir given by perf.
>>>>
>>>> When '--unpack' param is appointed, the symbols are extracted to '~/.debug'
>>>> folder by default, without using 'PERF_BUILDID_DIR' given by perf. This
>>>> will cause perf to be unable to find the correct buildid's path when users
>>>> configured buildid.dir in 'perf config' or used '--buildid-dir' cli param,
>>>> since perf will read these params and put them in 'PERF_BUILDID_DIR' env.
>>>> 'perf script' and 'perf report' will use the env as the basis for buildid
>>>> indexing.
>>>
>>> Can you please add an example command line and the output for the error
>>> case?  It'd be helpful to understand the problem more intuitively.
>>>
>>>>
> 
> [...]
> 
>>
>> I have two machines A and B, I use 'perf record' and 'perf archive' to get
>> a buildid archive 'perf.data.tar.bz2' on A: 
>>
>> $ perf record -a -g -- sleep 1
>> $ perf archive
>>
>> then I transfer 'perf.data' and its buildid archive to B. On machine B, I
>> use 'perf archive' to extract the buildid:
>>
>> $ perf archive --unpack
>> $   Found target file for unpacking: ./perf.data.tar.bz2
>> $   .build-id/d1/a727ab038085dbbb50e74c812e5a6e8502e8c7
>> $   ...
>>
>> But when I use 'perf script' to view hotspots, no function names are shown:
>>
>> $ perf script
>> $   No kallsyms or vmlinux with build-id 
>> $   251c1248b97a17df394058a189dffe381169ddcd was found
>> $   perf    1770 [000] 1022235.467607:          1 cycles:P: 
>> $           ffffffff8ae9ceb6 [unknown] ([kernel.kallsyms])
>> $           ffffffff8ae15af5 [unknown] ([kernel.kallsyms])
>> $           ffffffff8ae0f83b [unknown] ([kernel.kallsyms])
>> $   ......
>>
>> The problem is, I used 'perf config' to change buildid search path before:
>>
>> $ perf config --user buildid.dir=/usr/local/symbols
>> $ cat ~/.perfconfig
>> $   # this file is auto-generated.
>> $   [buildid]
>> $           dir = /usr/local/symbols
>>
> 
> Shouldn't then perf-archive just determine the directory from perf-config
> without any additional env var?
> 
>> But 'perf archive --unpack' just extract them to '~/.debug', which makes
>> perf can't found right path to search for buildid info. If I add
>> 'buildid-dir' param to replace buildid path defined in perfconfig, problem
>> can be solved temporarily:
>>
>> $ ./perf --buildid-dir ~/.debug script
>> $   perf    1770 [000] 1022235.467607:          1 cycles:P: 
>> $           ffffffff8ae9ceb6 native_write_msr+0x6 ([kernel.kallsyms])
>> $           ffffffff8ae15af5 intel_pmu_enable_all+0x15 ([kernel.kallsyms])
>> $           ffffffff8ae0f83b x86_pmu_enable+0x1ab ([kernel.kallsyms])
>>
>> The code that determines the buildid path is in the 
>> 'util/config.c:set_buildid_dir' function, which will generate
>> 'PERF_BUILDID_DIR' var.
> 
> As above, the var seems to be a duplicate to what is already stored in
> perf-config...
> 
>>
>>
> 
> Regards,
> Michael
> 

Sorry for the delay, I read about the codes, in 'perf.c:main', it will call
'perf_config' function at first, which will call 'config:set_buildid_dir'
to set an env 'PERF_BUILDID_DIR' for external commands(including
perf-archive). Codes are:

$ // perf.c
$ int main(int argc, const char **argv) {
$   // ...
$   err = perf_config(perf_default_config, NULL);
$   // ...
$ }
$
$ ...
$ // config.c
$ void set_buildid_dir(const char *dir) {
$   if (dir)
$	    scnprintf(buildid_dir, MAXPATHLEN, "%s", dir);
$
$	/* default to $HOME/.debug */
$	if (buildid_dir[0] == '\0') {
$		char *home = getenv("HOME");
$
$		if (home) {
$			snprintf(buildid_dir, MAXPATHLEN, "%s/%s",
$				 home, DEBUG_CACHE_DIR);
$		} else {
$			strncpy(buildid_dir, DEBUG_CACHE_DIR, MAXPATHLEN-1);
$		}
$		buildid_dir[MAXPATHLEN-1] = '\0';
$	}
$	/* for communicating with external commands */
$	setenv("PERF_BUILDID_DIR", buildid_dir, 1);
$ }

Or it will set to '${HOME}/.debug'('.debug' if ${HOME} not set).
'--buildid_dir' param will override it. So perf has already read the config
for us and set the 'PERF_BUILDID_DIR' env intentionally at first. I think
it's ok to use the env for indicating where to extract.

      reply	other threads:[~2024-07-23 17:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1720372219.git.royenheart@gmail.com>
2024-07-07 18:04 ` [PATCH 1/1] perf archive: unpack to correct dir given by perf Haoze Xie
2024-07-12  4:35   ` Namhyung Kim
2024-07-16 11:29     ` royenheart
2024-07-16 12:29       ` Michael Petlan
2024-07-23 17:26         ` Haoze Xie [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=85253bf0-7222-4abb-a583-6c55f949e6bd@gmail.com \
    --to=royenheart@gmail.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tanyuan@tinylab.org \
    --cc=vmolnaro@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 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).