All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Add an unresolved symbol for deleted binaries
@ 2011-05-11  1:03 Arun Sharma
  2011-06-02 19:20 ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 7+ messages in thread
From: Arun Sharma @ 2011-05-11  1:03 UTC (permalink / raw)
  To: acme; +Cc: linux-perf-users

[ Not sure if this is the best way to do it. Suggestions welcome ]

All samples that couldn't be resolved are attributed to this
synthetic symbol. This way, perf top correctly attributes the
samples to the right dso, even though it could not resolve the
address.

Signed-off-by: Arun Sharma <asharma@fb.com>
---
 tools/perf/util/map.c    |   50 +++++++++++++++++++++++++++++++++------------
 tools/perf/util/symbol.c |    4 +-
 tools/perf/util/symbol.h |    3 ++
 3 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 042ba9f..b525cba 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -1,4 +1,5 @@
 #include "symbol.h"
+#include <elf.h>
 #include <errno.h>
 #include <inttypes.h>
 #include <limits.h>
@@ -97,6 +98,26 @@ void map__fixup_end(struct map *self)
 }
 
 #define DSO__DELETED "(deleted)"
+static int check_deleted(struct map *self, const char *name,
+			 symbol_filter_t filter)
+{
+	const size_t len = strlen(name);
+	const size_t real_len = len - sizeof(DSO__DELETED);
+
+	if (len > sizeof(DSO__DELETED) &&
+	    strcmp(name + real_len + 1, DSO__DELETED) == 0) {
+		pr_warning("%.*s was updated, restart the long "
+			   "running apps that use it!\n",
+			   (int)real_len, name);
+
+		self->dso->unresolved_sym = symbol__new(1, 4, STB_GLOBAL,
+							"<unresolved>");
+		if (filter)
+			filter(self, self->dso->unresolved_sym);
+		return 1;
+	}
+	return 0;
+}
 
 int map__load(struct map *self, symbol_filter_t filter)
 {
@@ -116,27 +137,21 @@ int map__load(struct map *self, symbol_filter_t filter)
 					  sbuild_id);
 			pr_warning("%s with build id %s not found",
 				   name, sbuild_id);
-		} else
+		} else {
 			pr_warning("Failed to open %s", name);
+			self->dso->deleted = check_deleted(self, name, filter);
+			return 0;
+		}
 
 		pr_warning(", continuing without symbols\n");
 		return -1;
 	} else if (nr == 0) {
-		const size_t len = strlen(name);
-		const size_t real_len = len - sizeof(DSO__DELETED);
-
-		if (len > sizeof(DSO__DELETED) &&
-		    strcmp(name + real_len + 1, DSO__DELETED) == 0) {
-			pr_warning("%.*s was updated, restart the long "
-				   "running apps that use it!\n",
-				   (int)real_len, name);
-		} else {
+		self->dso->deleted = check_deleted(self, name, filter);
+		if (!self->dso->deleted) {
 			pr_warning("no symbols found in %s, maybe install "
 				   "a debug package?\n", name);
 		}
-
-		self->dso->deleted = 1;
-		return -1;
+		return 0;
 	}
 	/*
 	 * Only applies to the kernel, as its symtabs aren't relative like the
@@ -151,10 +166,17 @@ int map__load(struct map *self, symbol_filter_t filter)
 struct symbol *map__find_symbol(struct map *self, u64 addr,
 				symbol_filter_t filter)
 {
+	struct symbol *ret;
+
 	if (map__load(self, filter) < 0)
 		return NULL;
 
-	return dso__find_symbol(self->dso, self->type, addr);
+	ret = dso__find_symbol(self->dso, self->type, addr);
+
+	if (ret == NULL && self->dso->deleted)
+		return self->dso->unresolved_sym;
+
+	return ret;
 }
 
 struct symbol *map__find_symbol_by_name(struct map *self, const char *name,
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index dbd1944..a22b6b0 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -137,8 +137,8 @@ static void map_groups__fixup_end(struct map_groups *self)
 		__map_groups__fixup_end(self, i);
 }
 
-static struct symbol *symbol__new(u64 start, u64 len, u8 binding,
-				  const char *name)
+struct symbol *symbol__new(u64 start, u64 len, u8 binding,
+			  const char *name)
 {
 	size_t namelen = strlen(name) + 1;
 	struct symbol *self = calloc(1, (symbol_conf.priv_size +
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 943a054..d8a31a4 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -149,6 +149,7 @@ struct dso {
 	u8		 build_id[BUILD_ID_SIZE];
 	const char	 *short_name;
 	char	 	 *long_name;
+	struct symbol	 *unresolved_sym;
 	u16		 long_name_len;
 	u16		 short_name_len;
 	char		 name[0];
@@ -235,6 +236,8 @@ void machines__destroy_guest_kernel_maps(struct rb_root *self);
 int symbol__init(void);
 void symbol__exit(void);
 bool symbol_type__is_a(char symbol_type, enum map_type map_type);
+struct symbol *symbol__new(u64 start, u64 len, u8 binding,
+			   const char *name);
 
 size_t machine__fprintf_vmlinux_path(struct machine *self, FILE *fp);
 
-- 
1.7.4

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] Add an unresolved symbol for deleted binaries
  2011-05-11  1:03 [PATCH] Add an unresolved symbol for deleted binaries Arun Sharma
@ 2011-06-02 19:20 ` Arnaldo Carvalho de Melo
  2011-06-02 19:22   ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 7+ messages in thread
From: Arnaldo Carvalho de Melo @ 2011-06-02 19:20 UTC (permalink / raw)
  To: Arun Sharma; +Cc: linux-perf-users

Em Tue, May 10, 2011 at 06:03:05PM -0700, Arun Sharma escreveu:
> [ Not sure if this is the best way to do it. Suggestions welcome ]
> 
> All samples that couldn't be resolved are attributed to this
> synthetic symbol. This way, perf top correctly attributes the
> samples to the right dso, even though it could not resolve the
> address.

We can have multiple symtabs per dso: MAP__FUNCTION for code,
MAP__VARIABLE for data, so when using both types for a deleted dso we
would leak a variable so a test for dso->unresolved_symbol != NULL is
needed.

But I think here we want something else, make top deal with it,
basically using just one symbol object that it creates for such cases,
trying that approach now.

The first patch is fine (dso->deleted) and I applied it, thanks.

- Arnaldo
 
> Signed-off-by: Arun Sharma <asharma@fb.com>
> ---
>  tools/perf/util/map.c    |   50 +++++++++++++++++++++++++++++++++------------
>  tools/perf/util/symbol.c |    4 +-
>  tools/perf/util/symbol.h |    3 ++
>  3 files changed, 41 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index 042ba9f..b525cba 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -1,4 +1,5 @@
>  #include "symbol.h"
> +#include <elf.h>
>  #include <errno.h>
>  #include <inttypes.h>
>  #include <limits.h>
> @@ -97,6 +98,26 @@ void map__fixup_end(struct map *self)
>  }
>  
>  #define DSO__DELETED "(deleted)"
> +static int check_deleted(struct map *self, const char *name,
> +			 symbol_filter_t filter)
> +{
> +	const size_t len = strlen(name);
> +	const size_t real_len = len - sizeof(DSO__DELETED);
> +
> +	if (len > sizeof(DSO__DELETED) &&
> +	    strcmp(name + real_len + 1, DSO__DELETED) == 0) {
> +		pr_warning("%.*s was updated, restart the long "
> +			   "running apps that use it!\n",
> +			   (int)real_len, name);
> +
> +		self->dso->unresolved_sym = symbol__new(1, 4, STB_GLOBAL,
> +							"<unresolved>");
> +		if (filter)
> +			filter(self, self->dso->unresolved_sym);
> +		return 1;
> +	}
> +	return 0;
> +}
>  
>  int map__load(struct map *self, symbol_filter_t filter)
>  {
> @@ -116,27 +137,21 @@ int map__load(struct map *self, symbol_filter_t filter)
>  					  sbuild_id);
>  			pr_warning("%s with build id %s not found",
>  				   name, sbuild_id);
> -		} else
> +		} else {
>  			pr_warning("Failed to open %s", name);
> +			self->dso->deleted = check_deleted(self, name, filter);
> +			return 0;
> +		}
>  
>  		pr_warning(", continuing without symbols\n");
>  		return -1;
>  	} else if (nr == 0) {
> -		const size_t len = strlen(name);
> -		const size_t real_len = len - sizeof(DSO__DELETED);
> -
> -		if (len > sizeof(DSO__DELETED) &&
> -		    strcmp(name + real_len + 1, DSO__DELETED) == 0) {
> -			pr_warning("%.*s was updated, restart the long "
> -				   "running apps that use it!\n",
> -				   (int)real_len, name);
> -		} else {
> +		self->dso->deleted = check_deleted(self, name, filter);
> +		if (!self->dso->deleted) {
>  			pr_warning("no symbols found in %s, maybe install "
>  				   "a debug package?\n", name);
>  		}
> -
> -		self->dso->deleted = 1;
> -		return -1;
> +		return 0;
>  	}
>  	/*
>  	 * Only applies to the kernel, as its symtabs aren't relative like the
> @@ -151,10 +166,17 @@ int map__load(struct map *self, symbol_filter_t filter)
>  struct symbol *map__find_symbol(struct map *self, u64 addr,
>  				symbol_filter_t filter)
>  {
> +	struct symbol *ret;
> +
>  	if (map__load(self, filter) < 0)
>  		return NULL;
>  
> -	return dso__find_symbol(self->dso, self->type, addr);
> +	ret = dso__find_symbol(self->dso, self->type, addr);
> +
> +	if (ret == NULL && self->dso->deleted)
> +		return self->dso->unresolved_sym;
> +
> +	return ret;
>  }
>  
>  struct symbol *map__find_symbol_by_name(struct map *self, const char *name,
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index dbd1944..a22b6b0 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -137,8 +137,8 @@ static void map_groups__fixup_end(struct map_groups *self)
>  		__map_groups__fixup_end(self, i);
>  }
>  
> -static struct symbol *symbol__new(u64 start, u64 len, u8 binding,
> -				  const char *name)
> +struct symbol *symbol__new(u64 start, u64 len, u8 binding,
> +			  const char *name)
>  {
>  	size_t namelen = strlen(name) + 1;
>  	struct symbol *self = calloc(1, (symbol_conf.priv_size +
> diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
> index 943a054..d8a31a4 100644
> --- a/tools/perf/util/symbol.h
> +++ b/tools/perf/util/symbol.h
> @@ -149,6 +149,7 @@ struct dso {
>  	u8		 build_id[BUILD_ID_SIZE];
>  	const char	 *short_name;
>  	char	 	 *long_name;
> +	struct symbol	 *unresolved_sym;
>  	u16		 long_name_len;
>  	u16		 short_name_len;
>  	char		 name[0];
> @@ -235,6 +236,8 @@ void machines__destroy_guest_kernel_maps(struct rb_root *self);
>  int symbol__init(void);
>  void symbol__exit(void);
>  bool symbol_type__is_a(char symbol_type, enum map_type map_type);
> +struct symbol *symbol__new(u64 start, u64 len, u8 binding,
> +			   const char *name);
>  
>  size_t machine__fprintf_vmlinux_path(struct machine *self, FILE *fp);
>  
> -- 
> 1.7.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Add an unresolved symbol for deleted binaries
  2011-06-02 19:20 ` Arnaldo Carvalho de Melo
@ 2011-06-02 19:22   ` Arnaldo Carvalho de Melo
  2011-06-02 19:24     ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 7+ messages in thread
From: Arnaldo Carvalho de Melo @ 2011-06-02 19:22 UTC (permalink / raw)
  To: Arun Sharma; +Cc: linux-perf-users

Em Thu, Jun 02, 2011 at 04:20:18PM -0300, Arnaldo Carvalho de Melo escreveu:
> The first patch is fine (dso->deleted) and I applied it, thanks.

oops, it has a problem as well, we can't set ->deleted when we just
didn't found a symtab (stripped binary) fixing that.

- Arnaldo

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Add an unresolved symbol for deleted binaries
  2011-06-02 19:22   ` Arnaldo Carvalho de Melo
@ 2011-06-02 19:24     ` Arnaldo Carvalho de Melo
  2011-06-03  9:21       ` Not able to profile a 64bit application Kumar Ranjit-B04060
  0 siblings, 1 reply; 7+ messages in thread
From: Arnaldo Carvalho de Melo @ 2011-06-02 19:24 UTC (permalink / raw)
  To: Arun Sharma; +Cc: linux-perf-users

Em Thu, Jun 02, 2011 at 04:22:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Jun 02, 2011 at 04:20:18PM -0300, Arnaldo Carvalho de Melo escreveu:
> > The first patch is fine (dso->deleted) and I applied it, thanks.
> 
> oops, it has a problem as well, we can't set ->deleted when we just
> didn't found a symtab (stripped binary) fixing that.

oops, also we were setting it in map__load _after_ calling dso__load
that assumes it was already set, fixing that as well.

- Arnaldo

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Not able to profile a 64bit application
  2011-06-02 19:24     ` Arnaldo Carvalho de Melo
@ 2011-06-03  9:21       ` Kumar Ranjit-B04060
  2011-06-03 15:35         ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 7+ messages in thread
From: Kumar Ranjit-B04060 @ 2011-06-03  9:21 UTC (permalink / raw)
  To: linux-perf-users

I am able to do profiling using perf record and report for a 32 bit application but for 64 bit application, its not able to resolve the symbols.
Anyone faced similar problem??
I am doing this for e5500 core.

Regards

Ranjit Kumar
System Performance Team
Freescale 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Not able to profile a 64bit application
  2011-06-03  9:21       ` Not able to profile a 64bit application Kumar Ranjit-B04060
@ 2011-06-03 15:35         ` Arnaldo Carvalho de Melo
  2011-06-13  4:21           ` Kumar Ranjit-B04060
  0 siblings, 1 reply; 7+ messages in thread
From: Arnaldo Carvalho de Melo @ 2011-06-03 15:35 UTC (permalink / raw)
  To: Kumar Ranjit-B04060; +Cc: linux-perf-users

Em Fri, Jun 03, 2011 at 09:21:41AM +0000, Kumar Ranjit-B04060 escreveu:

> I am able to do profiling using perf record and report for a 32 bit
> application but for 64 bit application, its not able to resolve the
> symbols.  Anyone faced similar problem??

> I am doing this for e5500 core.

Can you provide some more details?

. Which distro
. readelf -s /path/to/your/64-bit/app output
. elfutils version

should be a good start.

- Arnaldo

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: Not able to profile a 64bit application
  2011-06-03 15:35         ` Arnaldo Carvalho de Melo
@ 2011-06-13  4:21           ` Kumar Ranjit-B04060
  0 siblings, 0 replies; 7+ messages in thread
From: Kumar Ranjit-B04060 @ 2011-06-13  4:21 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo; +Cc: linux-perf-users

Thanks Arnaldo,
Actually I am trying to profile coremark benchmark. So for a 32-bit coremark application I use the commands as
$./perf record -e cycles ./cmark_32bit.exe
$./perf report > profling_coremark_32bit

This generates proper output as (Putting only top few lines).
# Samples: 486793933
#
# Overhead          Command        Shared Object  Symbol
# ........  ...............  ...................  ......
#
    40.65%  cmark_32bit.exe  cmark_32bit.exe      [.] core_bench_state
    29.21%  cmark_32bit.exe  cmark_32bit.exe      [.] core_bench_list
    21.97%  cmark_32bit.exe  cmark_32bit.exe      [.] core_bench_matrix
     3.69%  cmark_32bit.exe  cmark_32bit.exe      [.] crc16
     3.45%  cmark_32bit.exe  cmark_32bit.exe      [.] crcu32
     0.79%  cmark_32bit.exe  cmark_32bit.exe      [.] crcu16
     0.13%  cmark_32bit.exe  [kernel.kallsyms]    [k] .raw_local_irq_restore
     0.01%  cmark_32bit.exe  [kernel.kallsyms]    [k] .memset
     0.01%  cmark_32bit.exe  [kernel.kallsyms]    [k] .rpc_set_active
     0.01%  cmark_32bit.exe  cmark_32bit.exe      [.] main


But when I repeat the procedure for a 64-bit application then there is some problem. I am putting my steps and the results I see
$rm perf.data
$./perf record -e cycles ./cmark_64.exe
$./perf report > profling_coremark_64bit

# Samples: 570272263
#
# Overhead       Command                Shared Object  Symbol
# ........  ............  ...........................  ......
#
    99.79%  cmark_64.exe  cmark_64.exe                 [.] 00000011.plt_call.putchar@@GLIBC_2.3+0
     0.08%  cmark_64.exe  [kernel.kallsyms]            [k] .raw_local_irq_restore
     0.01%  cmark_64.exe  [kernel.kallsyms]            [k] .memset
     0.01%  cmark_64.exe  [kernel.kallsyms]            [k] .run_timer_softirq
     0.01%  cmark_64.exe  [kernel.kallsyms]            [k] .rpc_set_active
     0.01%  cmark_64.exe  [kernel.kallsyms]            [k] .nfs_set_page_tag_locked
     0.01%  cmark_64.exe  [kernel.kallsyms]            [k] .kref_get
     0.01%  cmark_64.exe  [kernel.kallsyms]            [k] .__rpc_execute

Which is not correct.

Please let me know if you see some problem in my steps

Other details(uname -a)
Linux p5020ds-64b 2.6.34.6 #4 SMP Thu Jun 2 12:40:34 IST 2011 ppc64 GNU/Linux

I am using not using elfutils currently. I am using libelf-0.8.12/ from http://www.mr511.de/software/.
From your mail it looks like it should be a elfutils issue. So I will get elfutils today and build it.
Regards
Ranjit



-----Original Message-----
From: linux-perf-users-owner@vger.kernel.org [mailto:linux-perf-users-owner@vger.kernel.org] On Behalf Of Arnaldo Carvalho de Melo
Sent: Friday, June 03, 2011 9:06 PM
To: Kumar Ranjit-B04060
Cc: linux-perf-users@vger.kernel.org
Subject: Re: Not able to profile a 64bit application

Em Fri, Jun 03, 2011 at 09:21:41AM +0000, Kumar Ranjit-B04060 escreveu:

> I am able to do profiling using perf record and report for a 32 bit 
> application but for 64 bit application, its not able to resolve the 
> symbols.  Anyone faced similar problem??

> I am doing this for e5500 core.

Can you provide some more details?

. Which distro
. readelf -s /path/to/your/64-bit/app output . elfutils version

should be a good start.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2011-06-13  4:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-11  1:03 [PATCH] Add an unresolved symbol for deleted binaries Arun Sharma
2011-06-02 19:20 ` Arnaldo Carvalho de Melo
2011-06-02 19:22   ` Arnaldo Carvalho de Melo
2011-06-02 19:24     ` Arnaldo Carvalho de Melo
2011-06-03  9:21       ` Not able to profile a 64bit application Kumar Ranjit-B04060
2011-06-03 15:35         ` Arnaldo Carvalho de Melo
2011-06-13  4:21           ` Kumar Ranjit-B04060

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.