kernel/tools/perf/util/symbol-elf.c, branch linux-4.3.y

perf tools: Fix copying of /proc/kcore

2015-09-25T13:45:50Z

A copy of /proc/kcore containing the kernel text can be made to the buildid cache. e.g. perf buildid-cache -v -k /proc/kcore To workaround objdump limitations, a copy is also made when annotating against /proc/kcore. The copying process stops working from libelf about v1.62 onwards (the problem was found with v1.63). The cause is that a call to gelf_getphdr() in kcore__add_phdr() fails because additional validation has been added to gelf_getphdr(). The use of gelf_getphdr() is a misguided attempt to get default initialization of the Gelf_Phdr structure. That should not be necessary because every member of the Gelf_Phdr structure is subsequently assigned. So just remove the call to gelf_getphdr(). Similarly, a call to gelf_getehdr() in gelf_kcore__init() can be removed also. Committer notes: Note to stable@kernel.org, from Adrian in the cover letter for this patchkit: The "Fix copying of /proc/kcore" problem goes back to v3.13 if you think it is important enough for stable. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@kernel.org Link: http://lkml.kernel.org/r/1443089122-19082-3-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo

Revert "perf symbols: Fix mismatched declarations for elf_getphdrnum"

2015-09-17T16:10:05Z

This reverts commit f785f2357673d520a0b7b468973cdd197f336494. We have a test to check if elf_getphdrnum() is present, so, if it fails, we'll get: [acme@rhel5 linux]$ cat /tmp/build/perf/feature/test-libelf-getphdrnum.make.output cc1: warnings being treated as errors test-libelf-getphdrnum.c: In function ‘main’: test-libelf-getphdrnum.c:7: warning: implicit declaration of function ‘elf_getphdrnum’ [acme@rhel5 linux]$ And this block will not be compiled: #ifndef HAVE_ELF_GETPHDRNUM_SUPPORT static int elf_getphdrnum(Elf *elf, size_t *dst) ... #endif So, if elf_getphdrnum() is being defined somewhere, there is a problem with the test that is not detecting that function, go fix it. Reported-by: Vinson Lee Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: "Naveen N. Rao" Cc: Peter Zijlstra Cc: Srikar Dronamraju Cc: Stephane Eranian Cc: Victor Kamensky Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-qn459fal6acvcvm50i8zxx9k@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Fix annotation of vdso

2015-08-17T14:07:38Z

Older kernels attempt to prelink vdso to its virtual address. To permit annotation using objdump, the map__rip_2objdump() calculation must result in that same address which we can infer from the start and offset of the text section. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: Will Deacon Link: http://lkml.kernel.org/r/1439556606-11297-1-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Fix mismatched declarations for elf_getphdrnum

2015-07-29T13:51:45Z

When HAVE_ELF_GETPHDRNUM_SUPPORT is false we trip on this problem: CC /tmp/build/perf/util/symbol-elf.o util/symbol-elf.c:41:12: error: static declaration of ‘elf_getphdrnum’ follows non-static declaration static int elf_getphdrnum(Elf *elf, size_t *dst) ^ In file included from util/symbol.h:19:0, from util/symbol-elf.c:8: /usr/include/libelf.h:206:12: note: previous declaration of ‘elf_getphdrnum’ was here extern int elf_getphdrnum (Elf *__elf, size_t *__dst); ^ MKDIR /tmp/build/perf/bench/ /home/git/linux/tools/build/Makefile.build:68: recipe for target '/tmp/build/perf/util/symbol-elf.o' failed make[3]: *** [/tmp/build/perf/util/symbol-elf.o] Error 1 Fix it. Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-qcmekyfedmov4sxr0wahcikr@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Reference count struct dso

2015-06-08T13:31:40Z

This has a different model than the 'thread' and 'map' struct lifetimes: there is not a definitive "don't use this DSO anymore" event, i.e. we may get many 'struct map' holding references to the '/usr/lib64/libc-2.20.so' DSO but then at some point some DSO may have no references but we still don't want to straight away release its resources, because "soon" we may get a new 'struct map' that needs it and we want to reuse its symtab or other resources. So we need some way to garbage collect it when crossing some memory usage threshold, which is left for anoter patch, for now it is sufficient to release it when calling dsos__exit(), i.e. when deleting the whole list as part of deleting the 'struct machine' containing it, which will leave only referenced objects being used. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/n/tip-majzgz07cm90t2tejrjy4clf@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf machine: No need to have two DSOs lists

2015-05-29T15:43:43Z

We can, given a DSO, figure out if it is a kernel, a kernel module or a userlevel DSO, so stop having to process two lists in several functions. If searching becomes an issue at some point, we can have them in a rbtree, etc. Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Don Zickus Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-s4yb0onpdywu6dj2xl9lxi4t@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Reference count struct map

2015-05-27T23:27:30Z

We have pointers to struct map instances in several places, like in the hist_entry instances, so we need a way to know when we can destroy them, otherwise we may either keep leaking them or end up referencing deleted instances. Start fixing it by reference counting them. This patch puts the reference count for struct map in place, replacing direct map__delete() calls with map__put() ones and then grabbing a reference count when adding it to the maps struct where maps for a struct thread are kept. Next we'll grab reference counts when setting pointers to struct map instances, in places like in the hist_entry code. Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Don Zickus Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-wi19xczk0t2a41r1i2chuio5@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Warn on build id mismatch

2015-05-04T15:43:51Z

Add a debug message to indicate that the build id didn't match. Signed-off-by: Naveen N. Rao Link: http://lkml.kernel.org/r/1429904686-16516-1-git-send-email-naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo

perf probe ppc64le: Fix ppc64 ABIv2 symbol decoding

2015-05-04T15:43:45Z

ppc64 ELF ABIv2 has a Global Entry Point (GEP) and a Local Entry Point (LEP). For purposes of probing, we need the LEP - the offset to which is encoded in st_other. Signed-off-by: Ananth N Mavinakayanahalli Reviewed-by: Srikar Dronamraju Cc: Masami Hiramatsu Cc: Michael Ellerman Cc: Sukadev Bhattiprolu Cc: linuxppc-dev@lists.ozlabs.org Link: http://lkml.kernel.org/r/ab9cc5e2b9de4cbaaf50f6ef2346a6a81100bad1.1430217967.git.naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Naveen N. Rao Signed-off-by: Arnaldo Carvalho de Melo

perf probe ppc: Fix symbol fixup issues due to ELF type

2015-05-04T15:43:42Z

If using the symbol table, symbol addresses are not being fixed up properly, resulting in probes being placed at wrong addresses: # perf probe do_fork Added new event: probe:do_fork (on do_fork) You can now use it in all perf tools, such as: perf record -e probe:do_fork -aR sleep 1 # cat /sys/kernel/debug/tracing/kprobe_events p:probe/do_fork _text+635952 # printf "%x" 635952 9b430 # grep do_fork /boot/System.map c0000000000ab430 T .do_fork Fix by checking for ELF type ET_DYN used by ppc64 kernels. Signed-off-by: Naveen N. Rao Reviewed-by: Srikar Dronamraju Cc: Ananth N Mavinakayanahalli Cc: Masami Hiramatsu Cc: Michael Ellerman Cc: Sukadev Bhattiprolu Cc: linuxppc-dev@lists.ozlabs.org Link: http://lkml.kernel.org/r/41392bb856ef62d929995e0b61967689b7915207.1430217967.git.naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo