From: Adrian Hunter <adrian.hunter@intel.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: John Garry <john.garry@huawei.com>,
peterz@infradead.org, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@redhat.com,
namhyung@kernel.org, mingo@redhat.com, irogers@google.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
James Clark <James.Clark@arm.com>
Subject: Re: [RFC] Support Intel-PT code build in 32-bit arches
Date: Fri, 22 Oct 2021 15:23:53 +0300 [thread overview]
Message-ID: <becd9eb5-53d1-bde4-14a6-4ac2bb955508@intel.com> (raw)
In-Reply-To: <YXHOBXiIXP9b3xps@kernel.org>
On 21/10/2021 23:31, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 20, 2021 at 02:25:43PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Oct 20, 2021 at 03:41:01PM +0100, John Garry escreveu:
>>> I suppose the best thing now is to send a patch on top once perf/core
>>> contains that commit. Let me know otherwise.
>
>> You can send a v2, as:
>
>> 29 8.60 debian:experimental-x-mipsel : FAIL gcc version 11.2.0 (Debian 11.2.0-9)
>> util/intel-pt.c: In function 'intel_pt_synth_pebs_sample':
>> util/intel-pt.c:2146:33: error: passing argument 1 of 'find_first_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
>> 2146 | for_each_set_bit(hw_id, &items->applicable_counters, INTEL_PT_MAX_PEBS) {
>> /git/perf-5.15.0-rc4/tools/include/linux/bitops.h:37:38: note: in definition of macro 'for_each_set_bit'
>> 37 | for ((bit) = find_first_bit((addr), (size)); \
>> | ^~~~
>> In file included from /git/perf-5.15.0-rc4/tools/include/asm-generic/bitops.h:21,
>> from /git/perf-5.15.0-rc4/tools/include/linux/bitops.h:34,
>> from /git/perf-5.15.0-rc4/tools/include/linux/bitmap.h:6,
>> from util/header.h:10,
>> from util/session.h:7,
>> from util/intel-pt.c:16:
>> /git/perf-5.15.0-rc4/tools/include/asm-generic/bitops/find.h:109:51: note: expected 'const long unsigned int *' but argument is of type 'const uint64_t *' {aka 'const long long unsigned int *'}
>>
>> Adrian, this is on:
>>
>> commit 803a3c9233990e1adac8ea2421e3759c2d380cf8
>> Author: Adrian Hunter <adrian.hunter@intel.com>
>> Date: Tue Sep 7 19:39:03 2021 +0300
>>
>> perf intel-pt: Add support for PERF_RECORD_AUX_OUTPUT_HW_ID
>>
>> Originally, software only supported redirecting at most one PEBS event to
>> Intel PT (PEBS-via-PT) because it was not able to differentiate one event
>> from another. To overcome that, add support for the
>> PERF_RECORD_AUX_OUTPUT_HW_ID side-band event.
>>
>> Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>> Reviewed-by: Andi Kleen <ak@linux.intel.com>
>>
>>
>> That is still just on tmp.perf/core, so we can fix it, probably its just
>> making that uint64_t into a unsigned long, will check later if you don't
>> beat me to it.
>
> Adrian,
>
> Probably we should just disable Intel PT support from being
> built on 32-bit arches, right? I don't know if anybody is interested on
> that, my tests just try to figure out if it continues to build, and if
> fixing any problem isn't costly, which in this case is more than my
> threshold, wdyt?
It feels like bad form not to compile on 32-bit.
In this case we could just cast it, and I see that has been done
in other places for for_each_set_bit(), but (and maybe I've got
it wrong) that wouldn't work for a 32-bit big endian system?
The following might cover all cases, do you think?
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 1073c56a512c..7c979ffefade 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -2129,9 +2129,17 @@ static int intel_pt_synth_single_pebs_sample(struct intel_pt_queue *ptq)
return intel_pt_do_synth_pebs_sample(ptq, evsel, id);
}
+/* For 32-bit big endian, put the longs from u64 in correct order */
+#define U64_BITS(var, val) \
+ unsigned long var[] = { \
+ [0] = (val), \
+ [1] = (val) >> 32, \
+ }
+
static int intel_pt_synth_pebs_sample(struct intel_pt_queue *ptq)
{
const struct intel_pt_blk_items *items = &ptq->state->items;
+ U64_BITS(ac_bits, items->applicable_counters);
struct intel_pt_pebs_event *pe;
struct intel_pt *pt = ptq->pt;
int err = -EINVAL;
@@ -2143,7 +2151,7 @@ static int intel_pt_synth_pebs_sample(struct intel_pt_queue *ptq)
return intel_pt_synth_single_pebs_sample(ptq);
}
- for_each_set_bit(hw_id, &items->applicable_counters, INTEL_PT_MAX_PEBS) {
+ for_each_set_bit(hw_id, ac_bits, INTEL_PT_MAX_PEBS) {
pe = &ptq->pebs[hw_id];
if (!pe->evsel) {
if (!pt->single_pebs)
prev parent reply other threads:[~2021-10-22 12:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-15 16:48 [PATCH 0/2] perf jevents: Enable build warnings John Garry
2021-10-15 16:48 ` [PATCH 1/2] perf jevents: Fix some would-be warnings John Garry
2021-10-15 16:48 ` [PATCH 2/2] perf jevents: Enable warnings through HOSTCFLAGS John Garry
2021-10-18 10:41 ` James Clark
2021-10-19 8:37 ` John Garry
2021-10-20 14:31 ` [PATCH 0/2] perf jevents: Enable build warnings Arnaldo Carvalho de Melo
2021-10-20 14:41 ` John Garry
2021-10-20 16:34 ` Arnaldo Carvalho de Melo
2021-10-20 17:25 ` Arnaldo Carvalho de Melo
2021-10-21 20:31 ` [RFC] Support Intel-PT code build in 32-bit arches Arnaldo Carvalho de Melo
2021-10-22 12:23 ` Adrian Hunter [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=becd9eb5-53d1-bde4-14a6-4ac2bb955508@intel.com \
--to=adrian.hunter@intel.com \
--cc=James.Clark@arm.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=john.garry@huawei.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@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 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®