Re: [PATCHv6 0/4] perf: Add mmap2 build id support

From: Alexei Starovoitov
Date: Wed Jan 13 2021 - 22:28:19 EST


On Tue, Jan 12, 2021 at 1:19 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
>
> On Mon, Jan 11, 2021 at 06:49:58PM -0800, Alexei Starovoitov wrote:
> > On Mon, Jan 11, 2021 at 10:38:19PM +0100, Jiri Olsa wrote:
> > > hi,
> > > adding the support to have buildid stored in mmap2 event,
> > > so we can bypass the final perf record hunt on build ids.
> > >
> > > This patchset allows perf to record build ID in mmap2 event,
> > > and adds perf tooling to store/download binaries to .debug
> > > cache based on these build IDs.
> > >
> > > Note that the build id retrieval code is stolen from bpf
> > > code, where it's been used (together with file offsets)
> > > to replace IPs in user space stack traces. It's now added
> > > under lib directory.
> > >
> > > v6 changes:
> > > - last 4 patches rebased Arnaldo's perf/core
> >
> > There were no issues with v5 as far as I can remember.
> > This is just a resubmit to get it landed ?
>
> yes, exactly
>
> > Last time we couldn't quite figure out which tree to go through.
> > I think the recommend path was to go via bpf-next.
> > Is it still the case?
>
> bpf-next would be best for kernel changes,
> perf: Add build id data in mmap2 event
> bpf: Add size arg to build_id_parse function
> bpf: Move stack_map_get_build_id into lib

Then please cc them to bpf@vger and add [PATCH bpf-next]
otherwise it's all very confusing.

> the 'perf buildid-cache' change needs to go through Arnaldo's tree,
> because it depends on changes he already pulled in

Also don't include the 4th patch in the series if it isn't meant for bpf-next.