Re: [RFC/PATCH 00/14] perf record: Add support to store data in directory

[Jiri Olsa]

On Mon, Feb 11, 2019 at 12:43:22PM -0800, Stephane Eranian wrote:
> On Mon, Feb 11, 2019 at 12:18 PM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
> >
> > On Mon, Feb 11, 2019 at 04:32:02PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Feb 11, 2019 at 07:53:06PM +0100, Jiri Olsa escreveu:
> > > > On Mon, Feb 11, 2019 at 10:34:16AM -0800, Stephane Eranian wrote:
> > > > > On Mon, Feb 11, 2019 at 2:20 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
> > > > > > On Tue, Feb 05, 2019 at 02:37:27PM +0100, Jiri Olsa wrote:
> > > > > > I think all could be added and worked around with exception
> > > > > > of BUILD_ID, which we store at the end (after processing
> > > > > > all data) and we need it early in the report phase
> > >
> > > > > Buildids are injected after the fact via perf inject when in pipe mode.
> > >
> > > > > > maybe it's time to re-think that buildid -> mmap event
> > > > > > association again, because it's pain in current implementation
> > > > > > as well
> > >
> > > > > Sure, but what do you propose?
> > >
> > > > this:
> > > >
> > > > > > looks like bpf code is actualy getting build ids and storing
> > > > > > it for the callchains in kernel.. we can check if we can do
> > > > > > something similar for mmap events
> > >
> > > kernel/bpf/stackmap.c
> > >
> > > /* Parse build ID from 64-bit ELF */
> > > static int stack_map_get_build_id_64(void *page_addr,
> > >                                      unsigned char *build_id)
> > >
> > > yeah, wasn't aware of that, good thing doing backports, huh? :-)
> > >
> > > So do you thing about having a PERF_SAMPLE_BUILDID in sample_type and go
> > > and stash that thing in PERF_RECORD_MMAP2?
> >
> That would be special processing. Normally the sample_type go into
> each RECORD_SAMPLE.
> So I would not recommend this approach.
> 
> > I thought having new MMAP3 event version with buildid field in it
> > if available and/or enabled by bit in perf_event_attr
> >
> I think MMAP3 is a cleaner approach, though it adds yet another MMAP event.

actually I realized this might not help at the end at all

what we do now is that we scan the data (after it's recorded)
to get the list of binaries that got touched during the profile
and store those in .debug cache based on the build ids

we can't just store ALL of the binaries that the session comes
across via mmap events

I can see the build id in mmap helping to resolve the race
issue when some binary change during the profile session and
we have no idea and report on wrong one.. but I dont see
people complaining about this at all

jirka