On Tue, Nov 17, 2020 at 02:43:33PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 17, 2020 at 04:16:51PM +0100, Jiri Olsa escreveu: > > On Tue, Nov 17, 2020 at 09:44:37AM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Tue, Nov 17, 2020 at 12:00:42PM +0100, Jiri Olsa escreveu: > > > > Allow mmap2 event to synthesize kernel image, > > > > so we can synthesize kernel build id data in > > > > following changes. > > > > > > > > It's enabled by new symbol_conf.buildid_mmap2 > > > > bool, which will be switched in following > > > > changes. > > > > > > Why make this an option? MMAP2 goes back years: > > > > > > 13d7a2410fa637f45 (Stephane Eranian 2013-08-21 12:10:24 +0200 > > > 904) * The MMAP2 records are an augmented version of MMAP, they add > > > 13d7a2410fa637f45 (Stephane Eranian 2013-08-21 12:10:24 +0200 > > > 905) * maj, min, ino numbers to be used to uniquely identify each > > > mapping > > > > > > Also we unconditionally generate MMAP2 events if the kernel supports it, > > > from evsel__config(): > > > > > > attr->mmap = track; > > > attr->mmap2 = track && !perf_missing_features.mmap2; > > > > > > So perhaps we should reuse that logic? I.e. use mmap2 if the kernel > > > supports it? > > > > mmap2 itself is not a problem, the problem is the new > > bit (PERF_RECORD_MISC_MMAP_BUILD_ID) that says there's > > build id in mmap2.. older perf tool won't understand > > that and report will crash > > Is this theoretical or have you experienced it? > > Would be good to tweak the perf.data reader code to not crash on unknown > bits like that :-\ > > But by looking at machine__process_mmap2_event() I couldn't imagine how > that would crash. > > It would get bogus maj, min, ino, ino_generation, but probably that > wouldn't make it crash.
right, I shouldn't said crash, sry ;-) but bogus values are worse than that anyway jirka
