On 14/01/2026 3:47 pm, Arnaldo Carvalho de Melo wrote:

On Wed, Jan 14, 2026 at 12:14:43PM +0000, James Clark wrote:

quoted

On 13/01/2026 10:13 pm, Arnaldo Carvalho de Melo wrote:

quoted

On Mon, Dec 22, 2025 at 03:14:27PM +0000, James Clark wrote:

quoted

Make the evsel argument first to match the other evsel__* functions
and remove the redundant pmu argument, which can be accessed via evsel.

quoted

quoted

I haven't checked if this is the exactly where this takes place but
should be in this series, 32-bit build is broken:

quoted

quoted

     3: almalinux:9-i386WARNING: image platform (linux/386) does not match the expected platform (linux/amd64)
WARNING: image platform (linux/386) does not match the expected platform (linux/amd64)
      21.72 almalinux:9-i386              : FAIL gcc version 11.4.1 20231218 (Red Hat 11.4.1-3) (GCC)
       1378 |         perf_pmu__format_pack(&bits, val, vp, /*zero=*/true);
            |                               ^~~~~
            |                               |
            |                               u64 * {aka long long unsigned int *}
      In file included from util/evsel.h:14,
                       from util/evsel.c:38:
      util/pmu.h:282:43: note: expected ‘long unsigned int *’ but argument is of type ‘u64 *’ {aka ‘long long unsigned int *’}
        282 | void perf_pmu__format_pack(unsigned long *format, __u64 value, __u64 *v,
            |                            ~~~~~~~~~~~~~~~^~~~~~

quoted

quoted

What I have is in perf-tools-next/tmp.perf-tools-next BTW, I'll try and
fix this tomorrow if you don't do it first. :-)

quoted

Taking a look, but I'm wondering if this is already not working properly.
There are existing "unsigned long"s in pmu.c that operate on the config bits
which is what I copied.

quoted

On this target an unsigned long is 32bits but struct
perf_event_attr->configs are __u64. So it looks like it might leave the top
bits unset sometimes.

quoted

I'll look at a fix for that which should fix the compilation error at the
same time.

quoted

Another question is, do we actually care about this platform?

It failed for other 32-bit platforms too, so the question is if we care
about 32-bit at all.

- Arnaldo

I suppose the answer is we still do then.

I sent another version. A couple of patches were changed a bit where I 
used more bitfields instead of converting to u64s which was probably the 
right thing to do regardless of the build issue.