[PATCH] Add an unresolved symbol for deleted binaries

[PATCH] Add an unresolved symbol for deleted binaries

[Arun Sharma]

[ 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

Re: [PATCH] Add an unresolved symbol for deleted binaries

[Arnaldo Carvalho de Melo]

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

Re: [PATCH] Add an unresolved symbol for deleted binaries

[Arnaldo Carvalho de Melo]

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

Re: [PATCH] Add an unresolved symbol for deleted binaries

[Arnaldo Carvalho de Melo]

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

Not able to profile a 64bit application

[Kumar Ranjit-B04060]

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 

Re: Not able to profile a 64bit application

[Arnaldo Carvalho de Melo]

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

RE: Not able to profile a 64bit application

[Kumar Ranjit-B04060]

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