AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-21 10:06:00 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
bab89f6aed
linux_dsm_epyc7002/tools/perf/util/vdso.h

30 lines
600 B
C
Raw Normal View History

perf tools: Back [vdso] DSO with real data Storing data for VDSO shared object, because we need it for the post unwind processing. The VDSO shared object is same for all process on a running system, so it makes no difference when we store it inside the tracer - perf. When [vdso] map memory is hit, we retrieve [vdso] DSO image and store it into temporary file. During the build-id processing phase, the [vdso] DSO image is stored in build-id db, and build-id reference is made inside perf.data. The build-id vdso file object is called '[vdso]'. We don't use temporary file name which gets removed when record is finished. During report phase the vdso build-id object is treated as any other build-id DSO object. Adding following API for vdso object: bool is_vdso_map(const char *filename) - returns true if the filename matches vdso map name struct dso *vdso__dso_findnew(struct list_head *head) - find/create proper vdso DSO object vdso__exit(void) - removes temporary VDSO image if there's any This change makes backtrace dwarf post unwind possible from [vdso] maps. Following output is current report of [vdso] sample dwarf backtrace: # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.52% ex [vdso] [.] 0x00007fff3ace89af | --- 0x7fff3ace89af Following output is new report of [vdso] sample dwarf backtrace: # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.52% ex [vdso] [.] 0x00000000000009af | --- 0x7fff3ace89af main __libc_start_main _start Signed-off-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1347295819-23177-5-git-send-email-jolsa@redhat.com [ committer note: s/ALIGN/PERF_ALIGN/g to cope with the android build changes ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-09-10 23:50:19 +07:00
#ifndef __PERF_VDSO__
#define __PERF_VDSO__
#include <linux/types.h>
#include <string.h>
#include <stdbool.h>
#define VDSO__MAP_NAME "[vdso]"
perf tools: Add support for 32-bit compatibility VDSOs 'perf record' post-processes the event stream to create a list of build-ids for object files for which sample events have been recorded. That results in those object files being recorded in the build-id cache. In the case of VDSO, perf tools reads it from memory and copies it into a temporary file, which as decribed above, gets added to the build-id cache. Then when the perf.data file is processed by other tools, the build-id of VDSO is listed in the perf.data file and the VDSO can be read from the build-id cache. In that case the name of the map, the short name of the DSO, and the entry in the build-id cache are all "[vdso]". However, in the 64-bit case, there also can be 32-bit compatibility VDSOs. A previous patch added programs "perf-read-vdso32" and "perf read-vdsox32". This patch uses those programs to read the correct VDSO for a thread and create a temporary file just as for the 64-bit VDSO. The map name and the entry in the build-id cache are still "[vdso]" but the DSO short name becomes "[vdso32]" and "[vdsox32]" respectively. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1414061124-26830-16-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2014-10-23 17:45:23 +07:00
#define DSO__NAME_VDSO "[vdso]"
#define DSO__NAME_VDSO32 "[vdso32]"
#define DSO__NAME_VDSOX32 "[vdsox32]"
perf tools: Separate the VDSO map name from the VDSO dso name This is in preparation for supporting 32-bit compatibility VDSOs. Reviewed-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1406035081-14301-49-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2014-07-22 20:17:57 +07:00
perf tools: Back [vdso] DSO with real data Storing data for VDSO shared object, because we need it for the post unwind processing. The VDSO shared object is same for all process on a running system, so it makes no difference when we store it inside the tracer - perf. When [vdso] map memory is hit, we retrieve [vdso] DSO image and store it into temporary file. During the build-id processing phase, the [vdso] DSO image is stored in build-id db, and build-id reference is made inside perf.data. The build-id vdso file object is called '[vdso]'. We don't use temporary file name which gets removed when record is finished. During report phase the vdso build-id object is treated as any other build-id DSO object. Adding following API for vdso object: bool is_vdso_map(const char *filename) - returns true if the filename matches vdso map name struct dso *vdso__dso_findnew(struct list_head *head) - find/create proper vdso DSO object vdso__exit(void) - removes temporary VDSO image if there's any This change makes backtrace dwarf post unwind possible from [vdso] maps. Following output is current report of [vdso] sample dwarf backtrace: # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.52% ex [vdso] [.] 0x00007fff3ace89af | --- 0x7fff3ace89af Following output is new report of [vdso] sample dwarf backtrace: # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.52% ex [vdso] [.] 0x00000000000009af | --- 0x7fff3ace89af main __libc_start_main _start Signed-off-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1347295819-23177-5-git-send-email-jolsa@redhat.com [ committer note: s/ALIGN/PERF_ALIGN/g to cope with the android build changes ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-09-10 23:50:19 +07:00
static inline bool is_vdso_map(const char *filename)
{
return !strcmp(filename, VDSO__MAP_NAME);
}
perf tools: Separate the VDSO map name from the VDSO dso name This is in preparation for supporting 32-bit compatibility VDSOs. Reviewed-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1406035081-14301-49-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2014-07-22 20:17:57 +07:00
struct dso;
bool dso__is_vdso(struct dso *dso);
perf tools: Pass machine to vdso__dso_findnew() This is preparation for removing the global variables used in vdso.c and thereby fixing the lifetime of the VDSO temporary file. Reviewed-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1406035081-14301-45-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2014-07-22 20:17:53 +07:00
struct machine;
perf tools: Add thread parameter to vdso__dso_findnew() The thread will be needed to determine the VDSO type. Reviewed-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1406035081-14301-52-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2014-07-22 20:18:00 +07:00
struct thread;
perf tools: Pass machine to vdso__dso_findnew() This is preparation for removing the global variables used in vdso.c and thereby fixing the lifetime of the VDSO temporary file. Reviewed-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1406035081-14301-45-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2014-07-22 20:17:53 +07:00
perf machine: Fix up vdso methods names To make it consistent with the other dso lifetime routines. For instance: struct dso *vdso__new(struct machine *machine, const char *short_name, const char *long_name) Becomes: struct dso *machine__addnew_vdso(struct machine *machine, const char *short_name, const char *long_name) Because: 1) There is no 'struct vdso' for us to have vdso__ prefixed routines. 2) Because it will not really just create a new instance of 'struct dso', it'll call dso__new() but it will also insert it into the DSO's list/rbtree, and we have a method name for that: 'addnew', just like we have dsos__addnew(). 3) So it is really a 'struct machine' operation, it is the first argument, etc. This way the place where this is used gets consistent: if (vdso) { pgoff = 0; - dso = vdso__dso_findnew(machine, thread); + dso = machine__findnew_vdso(machine, thread); } else dso = machine__findnew_dso(machine, filename); Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/n/tip-r3w3tvh8exm9xfz3p4tz9qbz@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-29 21:54:08 +07:00
struct dso *machine__findnew_vdso(struct machine *machine, struct thread *thread);
void machine__exit_vdso(struct machine *machine);
perf tools: Back [vdso] DSO with real data Storing data for VDSO shared object, because we need it for the post unwind processing. The VDSO shared object is same for all process on a running system, so it makes no difference when we store it inside the tracer - perf. When [vdso] map memory is hit, we retrieve [vdso] DSO image and store it into temporary file. During the build-id processing phase, the [vdso] DSO image is stored in build-id db, and build-id reference is made inside perf.data. The build-id vdso file object is called '[vdso]'. We don't use temporary file name which gets removed when record is finished. During report phase the vdso build-id object is treated as any other build-id DSO object. Adding following API for vdso object: bool is_vdso_map(const char *filename) - returns true if the filename matches vdso map name struct dso *vdso__dso_findnew(struct list_head *head) - find/create proper vdso DSO object vdso__exit(void) - removes temporary VDSO image if there's any This change makes backtrace dwarf post unwind possible from [vdso] maps. Following output is current report of [vdso] sample dwarf backtrace: # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.52% ex [vdso] [.] 0x00007fff3ace89af | --- 0x7fff3ace89af Following output is new report of [vdso] sample dwarf backtrace: # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.52% ex [vdso] [.] 0x00000000000009af | --- 0x7fff3ace89af main __libc_start_main _start Signed-off-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1347295819-23177-5-git-send-email-jolsa@redhat.com [ committer note: s/ALIGN/PERF_ALIGN/g to cope with the android build changes ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-09-10 23:50:19 +07:00
#endif /* __PERF_VDSO__ */
Reference in New Issue Copy Permalink