Messages in this thread | | | Date | Tue, 16 Oct 2018 12:02:30 -0700 (PDT) | Subject | Re: perf's handling of unfindable user symbols... | From | David Miller <> |
| |
From: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Tue, 16 Oct 2018 15:45:06 -0300
> Exec summary: yeah, drop that hack, I agree, patch at the end of the > message. > > So, I thought something had changed and in the past we would somehow > find that address in the kallsyms, but I couldn't find anything to back > that up, the patch introducing this is over a decade old, lots of things > changed, so I was just thinking I was missing something. > > I tried a gtod busy loop to generate vdso activity and added a 'perf > probe' at that branch, on x86_64 to see if it ever gets hit:
Good, thanks for doing the detailed checking!
> In the process I noticed a bug, we're only have records for '[vdso]' for > pre-existing commands, i.e. ones that are running when we start 'perf top', > when we will generate the PERF_RECORD_MMAP by looking at /perf/PID/maps.
Hmmm. vdso mappings are installed by __install_special_mapping() which should be emitting proper mmap events by calling perf_event_mmap(vma).
Maybe the event is emitted too early? It doesn't look like it. These are emitted after load_elf_binary() iterates over the PHDRs and mmap()'s those areas of the binary, and we definitely see those events properly.
> The kernel doesn't seem to be generating a PERF_RECORD_MMAP for vDSOs... And > we can't do this in 'perf record' because we don't process event by event, just > dump things from the ring buffer to a file...
It should be, see above.
> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c > index 0988eb3b844b..bc646185f8d9 100644 > --- a/tools/perf/util/event.c > +++ b/tools/perf/util/event.c > @@ -1561,26 +1561,9 @@ struct map *thread__find_map(struct thread *thread, u8 cpumode, u64 addr, > > return NULL; > } > -try_again: > + > al->map = map_groups__find(mg, al->addr); > - if (al->map == NULL) { > - /* > - * If this is outside of all known maps, and is a negative > - * address, try to look it up in the kernel dso, as it might be > - * a vsyscall or vdso (which executes in user-mode). > - * > - * XXX This is nasty, we should have a symbol list in the > - * "[vdso]" dso, but for now lets use the old trick of looking > - * in the whole kernel symbol list. > - */ > - if (cpumode == PERF_RECORD_MISC_USER && machine && > - mg != &machine->kmaps && > - machine__kernel_ip(machine, al->addr)) { > - mg = &machine->kmaps; > - load_map = true; > - goto try_again; > - } > - } else { > + if (al->map != NULL) { > /* > * Kernel maps might be changed when loading symbols so loading > * must be done prior to using kernel maps. > >
Acked-by: David S. Miller <davem@davemloft.net>
:-)
| |