[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160115093436.GG3421@worktop>
Date: Fri, 15 Jan 2016 10:34:36 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Stephane Eranian <eranian@...gle.com>
Cc: Ingo Molnar <mingo@...nel.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>
Subject: Re: [RFC] perf record: missing buildid for callstack modules
On Thu, Jan 14, 2016 at 05:59:48PM -0800, Stephane Eranian wrote:
> Peter,
>
> On Thu, Jan 14, 2016 at 3:36 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Thu, Jan 14, 2016 at 12:27:34PM +0100, Ingo Molnar wrote:
> >> > + * u32 filename_len;
> >> > + * char filename[2+];
> >
> >> Acked-by: Ingo Molnar <mingo@...nel.org>
> >
> > except of course that sizeof(u32) == 4 :/
> There is no padding here. Are you concerned about running out of bits
> in filename_len?
No, I just made a mess of it :-)
filename_len should have been u16 and filename should then be 6+8n in
size.
> Any extension possible because header.size - sizeof(mmap3) -
> filename_len sizing what's after filename, right?
Right, current MMAP records use the remaining size as the filename
length, but by explicitly specifying that we can add optional fields.
These fields must be after filename_len, otherwise you'd not be able to
find filename_len and you could not compute the extra size. And given
alignment constraints it makes sense to do it after filename[].
So suppose we wanted to also add atime and ctime, we could do.
PERF_RECORD_MMAP3 {
...
u16 filename_len;
char filename[6+8n];
if (extra_size >= 16) {
u64 stime;
u64 ctime;
};
}
or something like that.
Powered by blists - more mailing lists