29 May, 2015
1 commit
-
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
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Link: http://lkml.kernel.org/n/tip-r3w3tvh8exm9xfz3p4tz9qbz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
29 Oct, 2014
1 commit
-
'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
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/1414061124-26830-16-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
24 Jul, 2014
4 commits
-
The thread will be needed to determine the VDSO type.
Reviewed-by: Jiri Olsa
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/1406035081-14301-52-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo -
This is in preparation for supporting 32-bit compatibility VDSOs.
Reviewed-by: Jiri Olsa
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/1406035081-14301-49-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo -
The VDSO temporary file is unlinked when a session is deleted. That
precludes the possibilities that there is no session or there is more
than one session.Correctly the vdso belongs to the machine so put the information on
'struct machine' and get rid of the global variables.Reviewed-by: Jiri Olsa
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/53CF9B14.7040408@intel.com
Signed-off-by: Arnaldo Carvalho de Melo -
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
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/1406035081-14301-45-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
11 Sep, 2012
1 commit
-
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 namestruct dso *vdso__dso_findnew(struct list_head *head)
- find/create proper vdso DSO objectvdso__exit(void)
- removes temporary VDSO image if there's anyThis 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
|
--- 0x7fff3ace89afFollowing output is new report of [vdso] sample dwarf backtrace:
# Overhead Command Shared Object Symbol
# ........ ....... ................. .............................
#
99.52% ex [vdso] [.] 0x00000000000009af
|
--- 0x7fff3ace89af
main
__libc_start_main
_startSigned-off-by: Jiri Olsa
Acked-by: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
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
