From: James Clark <james.clark@arm.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
John Garry <john.g.garry@oracle.com>,
Will Deacon <will@kernel.org>, Mike Leach <mike.leach@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Guo Ren <guoren@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>, Eric Lin <eric.lin@sifive.com>,
Kan Liang <kan.liang@linux.intel.com>,
Qi Liu <liuqi115@huawei.com>, Sandipan Das <sandipan.das@amd.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-csky@vger.kernel.org,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH v1 2/5] perf parse-regs: Introduce functions arch__reg_{ip|sp}()
Date: Mon, 22 May 2023 17:34:32 +0100 [thread overview]
Message-ID: <e2c04000-8e2e-e5ab-daea-a84d9519569f@arm.com> (raw)
In-Reply-To: <20230522120729.GB1826292@leoy-yangtze.lan>
On 22/05/2023 13:07, Leo Yan wrote:
> On Mon, May 22, 2023 at 09:57:25AM +0100, James Clark wrote:
>>
>>
>> On 20/05/2023 03:55, Leo Yan wrote:
>>> Ideally, we want util/perf_regs.c to be general enough and doesn't bind
>>> with specific architecture.
>>>
>>> But since util/perf_regs.c uses the macros PERF_REG_IP and PERF_REG_SP
>>> which are defined by architecture, thus util/perf_regs.c is dependent on
>>> architecture header (see util/perf_regs.h includes "<perf_regs.h>", here
>>> perf_regs.h is architecture specific header).
>>>
>>> As a step to generalize util/perf_regs.c, this commit introduces weak
>>> functions arch__reg_ip() and arch__reg_sp() and every architecture can
>>> define their own functions; thus, util/perf_regs.c doesn't need to use
>>> PERF_REG_IP and PERF_REG_SP anymore.
>>>
>>> This is a preparation to get rid of architecture specific header from
>>> util/perf_regs.h.
>>>
>>> Signed-off-by: Leo Yan <leo.yan@linaro.org>
>>> ---
>> [...]
>>>
>>> -#define DWARF_MINIMAL_REGS ((1ULL << PERF_REG_IP) | (1ULL << PERF_REG_SP))
>>> +#define DWARF_MINIMAL_REGS ((1ULL << arch__reg_ip()) | (1ULL << arch__reg_sp()))
>>>
>>> const char *perf_reg_name(int id, const char *arch);
>>> int perf_reg_value(u64 *valp, struct regs_dump *regs, int id);
>>> diff --git a/tools/perf/util/unwind-libdw.c b/tools/perf/util/unwind-libdw.c
>>> index bdccfc511b7e..f308f2ea512b 100644
>>> --- a/tools/perf/util/unwind-libdw.c
>>> +++ b/tools/perf/util/unwind-libdw.c
>>> @@ -252,7 +252,7 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
>>> if (!ui->dwfl)
>>> goto out;
>>>
>>> - err = perf_reg_value(&ip, &data->user_regs, PERF_REG_IP);
>>> + err = perf_reg_value(&ip, &data->user_regs, arch__reg_ip());
>>
>> Shouldn't it be more like this, because the weak symbols are a compile
>> time thing and it's supposed to support cross arch unwinding at runtime
>> (assuming something containing the arch from the file is passed down,
>> like we did with perf_reg_name()):
>>
>> char *arch = perf_env__arch(evsel__env(evsel));
>> err = perf_reg_value(&ip, &data->user_regs, arch__reg_ip(arch));
>
> Thanks for pointing out, James.
>
> Agreed that we need to return the IP and SP register based on the
> arch. I will look into more details and spin for a new patch set for
> this.
>
You might be able to skip the extra work for now though, seeing as your
change is no worse than it was before and it fixes the duplicate
declaration issue.
>> Now I'm wondering how cross unwinding ever worked because I see
>> libunwind also has something hard coded too:
>>
>> #define LIBUNWIND__ARCH_REG_SP PERF_REG_SP
>
> Yeah, I also used arch__reg_sp() to replace PERF_REG_SP; but as you
> suggestion, we should fix this with passing 'arch' parameter for
> getting SP register based on arch.
>
> Another important thing is to find a good test for cross unwinding.
> Maybe I can use tools/perf/tests/shell/record.sh, function
> test_register_capture() for testing registers, if you have any other
> suggesion, please let me know.
The only way I can think is to have pre-recorded perf.data files in the
repo, but they'd also need the binary from the recording too. I think
this is probably not a very good idea because it's going to make the
repo huge if we keep changing them (which we will).
Some kind of third party perf test suite hosted somewhere might work but
I don't think this exists.
>
> Thanks,
> Leo
next prev parent reply other threads:[~2023-05-22 16:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-20 2:55 [PATCH v1 0/5] perf parse-regs: Refactor arch related functions Leo Yan
2023-05-20 2:55 ` [PATCH v1 1/5] perf parse-regs: Refactor arch register parsing functions Leo Yan
2023-05-20 2:55 ` [PATCH v1 2/5] perf parse-regs: Introduce functions arch__reg_{ip|sp}() Leo Yan
2023-05-22 8:57 ` James Clark
2023-05-22 12:07 ` Leo Yan
2023-05-22 16:34 ` James Clark [this message]
2023-05-22 18:08 ` Ian Rogers
2023-05-23 6:49 ` Leo Yan
2023-05-20 2:55 ` [PATCH v1 3/5] perf parse-regs: Remove unused macros PERF_REG_{IP|SP} Leo Yan
2023-05-20 2:55 ` [PATCH v1 4/5] perf parse-regs: Remove PERF_REGS_{MAX|MASK} from common code Leo Yan
2023-05-20 2:55 ` [PATCH v1 5/5] perf parse-regs: Move out arch specific header from util/perf_regs.h Leo Yan
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=e2c04000-8e2e-e5ab-daea-a84d9519569f@arm.com \
--to=james.clark@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=aou@eecs.berkeley.edu \
--cc=eric.lin@sifive.com \
--cc=guoren@kernel.org \
--cc=irogers@google.com \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=liuqi115@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=sandipan.das@amd.com \
--cc=will@kernel.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 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).