Re: [PATCH] perf tools: Fix build failures on ppc64le

[Ian Rogers]

On Thu, Oct 10, 2024 at 11:34 PM Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
>
> On Fri, Oct 11, 2024 at 11:48:58AM +1100, Stephen Rothwell wrote:
> > Hi Namhyung,
> >
> > On Thu, 10 Oct 2024 16:57:43 -0700 Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
> > >
> > > Hi Stephen, can you please test if this patch fixes it?
> >
> > Sorry, I still get the same errors.
>
> Ok, thanks for the test.  I'll drop the series and rebase the branch.

Is this a define issue? I dislike that PPC has a #define
__SANE_USERSPACE_TYPES__, we might be trying to fix something
inherently insane.

The failure at:
```
    138 |         snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
        |                                               ~~~^
        |                                                  |
        |                                                  long long
unsigned int
        |                                               %lu
    139 |                  attr->type, attr->config, fd);
        |                              ~~~~~~~~~~~~
        |                                  |
        |                                  __u64 {aka long unsigned int}
  util/evsel.c:147:41: error: format '%llu' expects argument of type
'long long unsigned int',
                       but argument 4 has type '__u64' {aka 'long
unsigned int'} [-Werror=format=]
```
is for code moved from here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/tests/attr.c#n77
```
snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
attr->type, attr->config, fd);
```
ie the code is identical, so why does it compile in one file and not in another?

Elsewhere for PPC we carry:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/tests/bp_account.c#n3
```
/*
 * Powerpc needs __SANE_USERSPACE_TYPES__ before <linux/types.h> to select
 * 'int-ll64.h' and avoid compile warnings when printing __u64 with %llu.
 */
#define __SANE_USERSPACE_TYPES__
```
Given the comment I suspect we need to do similar to fix this.
Stephen, could you test?

Thanks,
Ian