Re: [RFC] perf record: missing buildid for callstack modules

[Stephane Eranian]

On Fri, Jan 15, 2016 at 11:49 AM, Arnaldo Carvalho de Melo
<acme@xxxxxxxxxx> wrote:
> Em Fri, Jan 15, 2016 at 10:58:48AM -0800, Stephane Eranian escreveu:
>> On Fri, Jan 15, 2016 at 1:34 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>> > 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@xxxxxxxxxxxxx> 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@xxxxxxxxxx>
>> >> >
>> >> > 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.
>> >
>> why don't you make it more explicit:
>>    u16 filename_len
>>    u16 extra_len
>
>> then it would be clear what is what, no field with dual meaning.
>> Now, that assumes that no pathname can be longer than 65535 bytes.
>
> There is no requirement for the filename to start at a u64 boundary,
> right? So it can start right after the filename_len, be it u16 or u32,
> and that extra_len can be computed as Peter described right here:
>
>> >> Any extension possible because header.size - sizeof(mmap3) -
>> >> filename_len sizing what's after filename, right?
>
> So, no need to have that extra_len :-)
>
I know it can. I just find this cumbersome to have to have to compose
fields to get the extra length. That would be

   extra = header.size - sizeof(header) - sizeof(all_the_data_fields)
- filename_len;

That's ugly and error prone. I know it's been used for other record
types. But maybe
we could avoid it here.


> Ah PATH_MAX is 4096, so I guess u16 should be enough, no?
>
> - Arnaldo
>
>> > 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.