On Tue, May 4, 2021 at 6:53 PM Rob Herring [off-list ref] wrote:

On Tue, May 4, 2021 at 2:43 PM Ian Rogers [off-list ref] wrote:

quoted

__u64 maybe an unsigned long, it may also differ from the format
expected by PRIu64. Add a cast to silence the warning:

tools/lib/perf/tests/test-evsel.c:176:33: error: format specifies type 'unsigned long long' but the argument has type 'unsigned long' [-Werror,-Wformat]
                __T_VERBOSE("count = %llu\n", end - start);
                                     ~~~~     ^~~~~~~~~~~
                                     %lu

Which arch/compiler did you hit this? LLVM? Would have been 64-bit
presumably. I'm wondering how I didn't...

quoted

Signed-off-by: Ian Rogers <irogers@google.com>
---
 tools/lib/perf/tests/test-evsel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/perf/tests/test-evsel.c b/tools/lib/perf/tests/test-evsel.c
index 288b5feaefe2..558097bbbfd0 100644
--- a/tools/lib/perf/tests/test-evsel.c
+++ b/tools/lib/perf/tests/test-evsel.c

@@ -173,7 +173,7 @@ static int test_stat_user_read(int event)

                __T("invalid counter data", (end - start) > last);
                last = end - start;
-               __T_VERBOSE("count = %llu\n", end - start);
+               __T_VERBOSE("count = %llu\n", (unsigned long long)(end - start));

I think I'd either change end/start to uint64_t which matches the
count struct and use PRIu64, or change them to unsigned long long.

Thanks! I need to dig into this again, I suspect there was a problem
on PowerPC defining s64/u64 to be long int. Perhaps this is happening
by way of a typedef using int64_t but more likely defining
__SANE_USERSPACE_TYPES__ is my fix. The guidance in the kernel on
formatters is pretty clear:
https://www.kernel.org/doc/Documentation/printk-formats.txt
And so I think it is better to fix the type for overall sanity and to drop this.

Thanks,
Ian

quoted

        }

        perf_evsel__munmap(evsel);
--
2.31.1.607.g51e8a6a459-goog