[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160617125042.24c554a7@gandalf.local.home>
Date: Fri, 17 Jun 2016 12:50:42 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Jeremy Linton <jeremy.linton@....com>
Cc: linux-kernel@...r.kernel.org, acme@...hat.com, namhyung@...nel.org,
kapileshwar.singh@....com, scottwood@...escale.com,
hekuang@...wei.com
Subject: Re: [RFC/PATCH] perf: Add sizeof operator support
On Fri, 17 Jun 2016 11:32:08 -0500
Jeremy Linton <jeremy.linton@....com> wrote:
> >> +
> >> + if (strcmp(token, "__u64") == 0) {
> >> + if (asprintf(&arg->atom.atom, "%zd", sizeof(__u64)) < 0)
> >> + goto out_free_atom;
> >> + } else if (strcmp(token, "__u32") == 0) {
> >> + if (asprintf(&arg->atom.atom, "%zd", sizeof(__u32)) < 0)
> >> + goto out_free_atom;
> >
> > What events are doing sizeof(__u64) and sizeof(__u32)?
> >
> > First, that's useless, as sizeof(__u64) will always be 8, and
> > sizeof(__u32) will always be 4.
> >
> > What exactly is this fixing?
>
> It starts to fix things like:
>
> kmem:mm_page_alloc
> Warning: [kmem:mm_page_alloc] function sizeof not defined
I don't see any sizeof() calls in my format files. And still, its
useless to add sizeof() for __u64 and __u32 unless perhaps a type is a
macro defined to that.
Ah, this is arm64 (as I don't see it in x86).
No the real fix is to nuke the sizeof(__u64) in the TP_printk(), it's
useless because it will always be 8.
-- Steve
>
> or:
>
> # perf stat -e kvm:kvm_arm_set_regset -- true
> Warning: [kvm:kvm_arm_set_regset] function sizeof not defined
> Warning: Error: expected type 5 but read 0
> *** Error in `perf': double free or corruption (fasttop):
> 0x00000000303f5930 ***
>
> There is a RH bug about it (and the "~" operator, which has been fixed)
> here: https://bugzilla.redhat.com/show_bug.cgi?id=1298229
>
> Thanks for taking a look at this,
Powered by blists - more mailing lists