All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] perf map: Do not display load warning for maps without dso
@ 2011-08-10 12:44 Jiri Olsa
  2011-08-22  7:53 ` Jiri Olsa
  0 siblings, 1 reply; 7+ messages in thread
From: Jiri Olsa @ 2011-08-10 12:44 UTC (permalink / raw)
  To: acme, a.p.zijlstra, mingo, paulus; +Cc: linux-kernel, Jiri Olsa

hi,
I get unnecessary warnings from map__load about "[stack]" maps,
saying dso cannot be loaded.

Attached patch avoids this warning for maps that are
not backed-up by dso.

I was wondering if we want to treat stack/heaps/vdso maps
the same way or if there's something special about vdso
in this regard. Because there could be another fix with
setting all stack/heaps/vdso maps as loaded, which
is probably little more nicer.

thanks,
jirka

---
When report command proceses adress hits, it tries to resolve
them in to the symbol names. This is not possible for stack
and heap memory maps, because they are not backed-up by any
binary or dso.

This patch avoids the warning "Failed to open..." inside the
map__load function for stack and heap maps.

Signed-off-by: Jiri Olsa <jolsa@redhat.com>
---
 tools/perf/util/map.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index a16ecab..ac5fb40 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -18,6 +18,14 @@ static inline int is_anon_memory(const char *filename)
 	return strcmp(filename, "//anon") == 0;
 }
 
+static inline int is_no_dso_memory(struct map *self)
+{
+	const char *name = self->dso->long_name;
+
+	return (!strcmp(name, "[stack]") ||
+		!strcmp(name, "[heap]"));
+}
+
 void map__init(struct map *self, enum map_type type,
 	       u64 start, u64 end, u64 pgoff, struct dso *dso)
 {
@@ -108,6 +116,13 @@ int map__load(struct map *self, symbol_filter_t filter)
 
 	nr = dso__load(self->dso, self, filter);
 	if (nr < 0) {
+		/*
+		 * Do not print warning for maps that cannot
+		 * be loaded anyway.
+		 */
+		if (is_no_dso_memory(self))
+			return -1;
+
 		if (self->dso->has_build_id) {
 			char sbuild_id[BUILD_ID_SIZE * 2 + 1];
 
-- 
1.7.1


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

* Re: [PATCH] perf map: Do not display load warning for maps without dso
  2011-08-10 12:44 [PATCH] perf map: Do not display load warning for maps without dso Jiri Olsa
@ 2011-08-22  7:53 ` Jiri Olsa
  2011-08-22 14:11   ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 7+ messages in thread
From: Jiri Olsa @ 2011-08-22  7:53 UTC (permalink / raw)
  To: acme, a.p.zijlstra, mingo, paulus; +Cc: linux-kernel

hi,
any feedback on this?

thanks,
jirka

On Wed, Aug 10, 2011 at 02:44:11PM +0200, Jiri Olsa wrote:
> hi,
> I get unnecessary warnings from map__load about "[stack]" maps,
> saying dso cannot be loaded.
> 
> Attached patch avoids this warning for maps that are
> not backed-up by dso.
> 
> I was wondering if we want to treat stack/heaps/vdso maps
> the same way or if there's something special about vdso
> in this regard. Because there could be another fix with
> setting all stack/heaps/vdso maps as loaded, which
> is probably little more nicer.
> 
> thanks,
> jirka
> 
> ---
> When report command proceses adress hits, it tries to resolve
> them in to the symbol names. This is not possible for stack
> and heap memory maps, because they are not backed-up by any
> binary or dso.
> 
> This patch avoids the warning "Failed to open..." inside the
> map__load function for stack and heap maps.
> 
> Signed-off-by: Jiri Olsa <jolsa@redhat.com>
> ---
>  tools/perf/util/map.c |   15 +++++++++++++++
>  1 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index a16ecab..ac5fb40 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -18,6 +18,14 @@ static inline int is_anon_memory(const char *filename)
>  	return strcmp(filename, "//anon") == 0;
>  }
>  
> +static inline int is_no_dso_memory(struct map *self)
> +{
> +	const char *name = self->dso->long_name;
> +
> +	return (!strcmp(name, "[stack]") ||
> +		!strcmp(name, "[heap]"));
> +}
> +
>  void map__init(struct map *self, enum map_type type,
>  	       u64 start, u64 end, u64 pgoff, struct dso *dso)
>  {
> @@ -108,6 +116,13 @@ int map__load(struct map *self, symbol_filter_t filter)
>  
>  	nr = dso__load(self->dso, self, filter);
>  	if (nr < 0) {
> +		/*
> +		 * Do not print warning for maps that cannot
> +		 * be loaded anyway.
> +		 */
> +		if (is_no_dso_memory(self))
> +			return -1;
> +
>  		if (self->dso->has_build_id) {
>  			char sbuild_id[BUILD_ID_SIZE * 2 + 1];
>  
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

* Re: [PATCH] perf map: Do not display load warning for maps without dso
  2011-08-22  7:53 ` Jiri Olsa
@ 2011-08-22 14:11   ` Arnaldo Carvalho de Melo
  2011-08-22 14:58     ` Jiri Olsa
  0 siblings, 1 reply; 7+ messages in thread
From: Arnaldo Carvalho de Melo @ 2011-08-22 14:11 UTC (permalink / raw)
  To: Jiri Olsa; +Cc: a.p.zijlstra, mingo, paulus, linux-kernel

Em Mon, Aug 22, 2011 at 09:53:22AM +0200, Jiri Olsa escreveu:
> hi,
> any feedback on this?

Fell thru the cracks, sorry.
 
> On Wed, Aug 10, 2011 at 02:44:11PM +0200, Jiri Olsa wrote:
> > I get unnecessary warnings from map__load about "[stack]" maps,
> > saying dso cannot be loaded.

> > Attached patch avoids this warning for maps that are not backed-up
> > by dso.

> > I was wondering if we want to treat stack/heaps/vdso maps the same
> > way or if there's something special about vdso in this regard.
> > Because there could be another fix with setting all stack/heaps/vdso
> > maps as loaded, which is probably little more nicer.

Humm, in the vdso case we have a fallback in thread__find_addr_map, i.e.
its symbol rbtree is empty, we notice that and lookup the symbol in the
kernel symbol tables (vmlinux and modules).

I.e. stack/heap symbols would not apply, this fallback wouldn't happen,
the symbol would be unresolved, the patch then would be just to
map__new, as:

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index a16ecab..0c1c11b 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -63,7 +63,9 @@ set_identity:
 		} else if (strcmp(filename, "[vdso]") == 0) {
 			dso__set_loaded(dso, self->type);
 			goto set_identity;
-		}
+		} else if (strcmp(filename, "[heap]") == 0 ||
+			   strcmp(filename, "[stack]") == 0)
+			dso__set_loaded(dso, self->type);
 	}
 	return self;
 out_delete:

Right?

- Arnaldo

> > ---
> > When report command proceses adress hits, it tries to resolve
> > them in to the symbol names. This is not possible for stack
> > and heap memory maps, because they are not backed-up by any
> > binary or dso.
> > 
> > This patch avoids the warning "Failed to open..." inside the
> > map__load function for stack and heap maps.
> > 
> > Signed-off-by: Jiri Olsa <jolsa@redhat.com>
> > ---
> >  tools/perf/util/map.c |   15 +++++++++++++++
> >  1 files changed, 15 insertions(+), 0 deletions(-)
> > 
> > diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> > index a16ecab..ac5fb40 100644
> > --- a/tools/perf/util/map.c
> > +++ b/tools/perf/util/map.c
> > @@ -18,6 +18,14 @@ static inline int is_anon_memory(const char *filename)
> >  	return strcmp(filename, "//anon") == 0;
> >  }
> >  
> > +static inline int is_no_dso_memory(struct map *self)
> > +{
> > +	const char *name = self->dso->long_name;
> > +
> > +	return (!strcmp(name, "[stack]") ||
> > +		!strcmp(name, "[heap]"));
> > +}
> > +
> >  void map__init(struct map *self, enum map_type type,
> >  	       u64 start, u64 end, u64 pgoff, struct dso *dso)
> >  {
> > @@ -108,6 +116,13 @@ int map__load(struct map *self, symbol_filter_t filter)
> >  
> >  	nr = dso__load(self->dso, self, filter);
> >  	if (nr < 0) {
> > +		/*
> > +		 * Do not print warning for maps that cannot
> > +		 * be loaded anyway.
> > +		 */
> > +		if (is_no_dso_memory(self))
> > +			return -1;
> > +
> >  		if (self->dso->has_build_id) {
> >  			char sbuild_id[BUILD_ID_SIZE * 2 + 1];

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

* Re: [PATCH] perf map: Do not display load warning for maps without dso
  2011-08-22 14:11   ` Arnaldo Carvalho de Melo
@ 2011-08-22 14:58     ` Jiri Olsa
  2011-08-24 13:18       ` [PATCH] perf, tool: Treat all memory maps without dso file as loaded Jiri Olsa
  0 siblings, 1 reply; 7+ messages in thread
From: Jiri Olsa @ 2011-08-22 14:58 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo; +Cc: a.p.zijlstra, mingo, paulus, linux-kernel

On Mon, Aug 22, 2011 at 11:11:30AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Aug 22, 2011 at 09:53:22AM +0200, Jiri Olsa escreveu:
> > hi,
> > any feedback on this?
> 
> Fell thru the cracks, sorry.
>  
> > On Wed, Aug 10, 2011 at 02:44:11PM +0200, Jiri Olsa wrote:
> > > I get unnecessary warnings from map__load about "[stack]" maps,
> > > saying dso cannot be loaded.
> 
> > > Attached patch avoids this warning for maps that are not backed-up
> > > by dso.
> 
> > > I was wondering if we want to treat stack/heaps/vdso maps the same
> > > way or if there's something special about vdso in this regard.
> > > Because there could be another fix with setting all stack/heaps/vdso
> > > maps as loaded, which is probably little more nicer.
> 
> Humm, in the vdso case we have a fallback in thread__find_addr_map, i.e.
> its symbol rbtree is empty, we notice that and lookup the symbol in the
> kernel symbol tables (vmlinux and modules).
> 
> I.e. stack/heap symbols would not apply, this fallback wouldn't happen,
> the symbol would be unresolved, the patch then would be just to
> map__new, as:
> 
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index a16ecab..0c1c11b 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -63,7 +63,9 @@ set_identity:
>  		} else if (strcmp(filename, "[vdso]") == 0) {
>  			dso__set_loaded(dso, self->type);
>  			goto set_identity;
> -		}
> +		} else if (strcmp(filename, "[heap]") == 0 ||
> +			   strcmp(filename, "[stack]") == 0)
> +			dso__set_loaded(dso, self->type);
>  	}
>  	return self;
>  out_delete:
> 
> Right?

yes, I was not completely sure I was not breaking anything else,
so I posted the first patch.. the original patch I had is attached.

I haven't tested this one much though.. let me know and
I can resend this one with changelog/testing..

thanks,
jirka

---
 tools/perf/util/map.c |   24 ++++++++++++++++++------
 1 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index a16ecab..a5e9007 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -18,6 +18,13 @@ static inline int is_anon_memory(const char *filename)
 	return strcmp(filename, "//anon") == 0;
 }
 
+static inline int is_no_dso_memory(const char *filename)
+{
+	return (!strcmp(filename, "[stack]") ||
+		!strcmp(filename, "[vdso]")  ||
+		!strcmp(filename, "[heap]"));
+}
+
 void map__init(struct map *self, enum map_type type,
 	       u64 start, u64 end, u64 pgoff, struct dso *dso)
 {
@@ -42,9 +49,10 @@ struct map *map__new(struct list_head *dsos__list, u64 start, u64 len,
 	if (self != NULL) {
 		char newfilename[PATH_MAX];
 		struct dso *dso;
-		int anon;
+		int anon, no_dso;
 
 		anon = is_anon_memory(filename);
+		no_dso = is_no_dso_memory(filename);
 
 		if (anon) {
 			snprintf(newfilename, sizeof(newfilename), "/tmp/perf-%d.map", pid);
@@ -57,12 +65,16 @@ struct map *map__new(struct list_head *dsos__list, u64 start, u64 len,
 
 		map__init(self, type, start, start + len, pgoff, dso);
 
-		if (anon) {
-set_identity:
+		if (anon || no_dso) {
 			self->map_ip = self->unmap_ip = identity__map_ip;
-		} else if (strcmp(filename, "[vdso]") == 0) {
-			dso__set_loaded(dso, self->type);
-			goto set_identity;
+
+			/*
+			 * Set memory without DSO as loaded. All map__find_*
+			 * functions still return NULL, and we avoid the
+			 * unnecessary map_load warning.
+			 */
+			if (no_dso)
+				dso__set_loaded(dso, self->type);
 		}
 	}
 	return self;
-- 
1.7.1



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

* [PATCH] perf, tool: Treat all memory maps without dso file as loaded
  2011-08-22 14:58     ` Jiri Olsa
@ 2011-08-24 13:18       ` Jiri Olsa
  2011-09-29 16:11         ` Jiri Olsa
  0 siblings, 1 reply; 7+ messages in thread
From: Jiri Olsa @ 2011-08-24 13:18 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo; +Cc: a.p.zijlstra, mingo, paulus, linux-kernel

On Mon, Aug 22, 2011 at 04:58:49PM +0200, Jiri Olsa wrote:
> On Mon, Aug 22, 2011 at 11:11:30AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Aug 22, 2011 at 09:53:22AM +0200, Jiri Olsa escreveu:
> > > hi,
> > > any feedback on this?
> > 
> > Fell thru the cracks, sorry.
> >  
> > > On Wed, Aug 10, 2011 at 02:44:11PM +0200, Jiri Olsa wrote:
> > > > I get unnecessary warnings from map__load about "[stack]" maps,
> > > > saying dso cannot be loaded.
> > 
> > > > Attached patch avoids this warning for maps that are not backed-up
> > > > by dso.
> > 
> > > > I was wondering if we want to treat stack/heaps/vdso maps the same
> > > > way or if there's something special about vdso in this regard.
> > > > Because there could be another fix with setting all stack/heaps/vdso
> > > > maps as loaded, which is probably little more nicer.
> > 
> > Humm, in the vdso case we have a fallback in thread__find_addr_map, i.e.
> > its symbol rbtree is empty, we notice that and lookup the symbol in the
> > kernel symbol tables (vmlinux and modules).
> > 
> > I.e. stack/heap symbols would not apply, this fallback wouldn't happen,
> > the symbol would be unresolved, the patch then would be just to
> > map__new, as:
> > 
> > diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> > index a16ecab..0c1c11b 100644
> > --- a/tools/perf/util/map.c
> > +++ b/tools/perf/util/map.c
> > @@ -63,7 +63,9 @@ set_identity:
> >  		} else if (strcmp(filename, "[vdso]") == 0) {
> >  			dso__set_loaded(dso, self->type);
> >  			goto set_identity;
> > -		}
> > +		} else if (strcmp(filename, "[heap]") == 0 ||
> > +			   strcmp(filename, "[stack]") == 0)
> > +			dso__set_loaded(dso, self->type);
> >  	}
> >  	return self;
> >  out_delete:
> > 
> > Right?
> 
> yes, I was not completely sure I was not breaking anything else,
> so I posted the first patch.. the original patch I had is attached.
> 
> I haven't tested this one much though.. let me know and
> I can resend this one with changelog/testing..

and here it is ;)

thanks,
jirka

---
The stack/vdso/heap memory maps dont have any dso file.
Setting the perf dso objects as 'loaded' for these maps,
we avoid unnecessary warnings like:

  "Failed to open [stack], continuing without symbols"

All map__find_* functions still return NULL when searching
for symbols in these maps.

Signed-off-by: Jiri Olsa <jolsa@redhat.com>
---
 tools/perf/util/map.c |   24 ++++++++++++++++++------
 1 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index a16ecab..7e218e3 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -18,6 +18,13 @@ static inline int is_anon_memory(const char *filename)
 	return strcmp(filename, "//anon") == 0;
 }
 
+static inline int is_no_dso_memory(const char *filename)
+{
+	return !strcmp(filename, "[stack]") ||
+	       !strcmp(filename, "[vdso]")  ||
+	       !strcmp(filename, "[heap]");
+}
+
 void map__init(struct map *self, enum map_type type,
 	       u64 start, u64 end, u64 pgoff, struct dso *dso)
 {
@@ -42,9 +49,10 @@ struct map *map__new(struct list_head *dsos__list, u64 start, u64 len,
 	if (self != NULL) {
 		char newfilename[PATH_MAX];
 		struct dso *dso;
-		int anon;
+		int anon, no_dso;
 
 		anon = is_anon_memory(filename);
+		no_dso = is_no_dso_memory(filename);
 
 		if (anon) {
 			snprintf(newfilename, sizeof(newfilename), "/tmp/perf-%d.map", pid);
@@ -57,12 +65,16 @@ struct map *map__new(struct list_head *dsos__list, u64 start, u64 len,
 
 		map__init(self, type, start, start + len, pgoff, dso);
 
-		if (anon) {
-set_identity:
+		if (anon || no_dso) {
 			self->map_ip = self->unmap_ip = identity__map_ip;
-		} else if (strcmp(filename, "[vdso]") == 0) {
-			dso__set_loaded(dso, self->type);
-			goto set_identity;
+
+			/*
+			 * Set memory without DSO as loaded. All map__find_*
+			 * functions still return NULL, and we avoid the
+			 * unnecessary map__load warning.
+			 */
+			if (no_dso)
+				dso__set_loaded(dso, self->type);
 		}
 	}
 	return self;
-- 
1.7.4


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

* Re: [PATCH] perf, tool: Treat all memory maps without dso file as loaded
  2011-08-24 13:18       ` [PATCH] perf, tool: Treat all memory maps without dso file as loaded Jiri Olsa
@ 2011-09-29 16:11         ` Jiri Olsa
  2011-09-29 22:09           ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 7+ messages in thread
From: Jiri Olsa @ 2011-09-29 16:11 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo; +Cc: a.p.zijlstra, mingo, paulus, linux-kernel

On Wed, Aug 24, 2011 at 03:18:34PM +0200, Jiri Olsa wrote:
> On Mon, Aug 22, 2011 at 04:58:49PM +0200, Jiri Olsa wrote:
> > On Mon, Aug 22, 2011 at 11:11:30AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Aug 22, 2011 at 09:53:22AM +0200, Jiri Olsa escreveu:
> > > > hi,
> > > > any feedback on this?
> > > 
> > > Fell thru the cracks, sorry.
> > >  
> > > > On Wed, Aug 10, 2011 at 02:44:11PM +0200, Jiri Olsa wrote:
> > > > > I get unnecessary warnings from map__load about "[stack]" maps,
> > > > > saying dso cannot be loaded.
> > > 
> > > > > Attached patch avoids this warning for maps that are not backed-up
> > > > > by dso.
> > > 
> > > > > I was wondering if we want to treat stack/heaps/vdso maps the same
> > > > > way or if there's something special about vdso in this regard.
> > > > > Because there could be another fix with setting all stack/heaps/vdso
> > > > > maps as loaded, which is probably little more nicer.
> > > 
> > > Humm, in the vdso case we have a fallback in thread__find_addr_map, i.e.
> > > its symbol rbtree is empty, we notice that and lookup the symbol in the
> > > kernel symbol tables (vmlinux and modules).
> > > 
> > > I.e. stack/heap symbols would not apply, this fallback wouldn't happen,
> > > the symbol would be unresolved, the patch then would be just to
> > > map__new, as:
> > > 
> > > diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> > > index a16ecab..0c1c11b 100644
> > > --- a/tools/perf/util/map.c
> > > +++ b/tools/perf/util/map.c
> > > @@ -63,7 +63,9 @@ set_identity:
> > >  		} else if (strcmp(filename, "[vdso]") == 0) {
> > >  			dso__set_loaded(dso, self->type);
> > >  			goto set_identity;
> > > -		}
> > > +		} else if (strcmp(filename, "[heap]") == 0 ||
> > > +			   strcmp(filename, "[stack]") == 0)
> > > +			dso__set_loaded(dso, self->type);
> > >  	}
> > >  	return self;
> > >  out_delete:
> > > 
> > > Right?
> > 
> > yes, I was not completely sure I was not breaking anything else,
> > so I posted the first patch.. the original patch I had is attached.
> > 
> > I haven't tested this one much though.. let me know and
> > I can resend this one with changelog/testing..
> 
> and here it is ;)

hi,
any feedback?

thanks,
jirka






> 
> thanks,
> jirka
> 
> ---
> The stack/vdso/heap memory maps dont have any dso file.
> Setting the perf dso objects as 'loaded' for these maps,
> we avoid unnecessary warnings like:
> 
>   "Failed to open [stack], continuing without symbols"
> 
> All map__find_* functions still return NULL when searching
> for symbols in these maps.
> 
> Signed-off-by: Jiri Olsa <jolsa@redhat.com>
> ---
>  tools/perf/util/map.c |   24 ++++++++++++++++++------
>  1 files changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index a16ecab..7e218e3 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -18,6 +18,13 @@ static inline int is_anon_memory(const char *filename)
>  	return strcmp(filename, "//anon") == 0;
>  }
>  
> +static inline int is_no_dso_memory(const char *filename)
> +{
> +	return !strcmp(filename, "[stack]") ||
> +	       !strcmp(filename, "[vdso]")  ||
> +	       !strcmp(filename, "[heap]");
> +}
> +
>  void map__init(struct map *self, enum map_type type,
>  	       u64 start, u64 end, u64 pgoff, struct dso *dso)
>  {
> @@ -42,9 +49,10 @@ struct map *map__new(struct list_head *dsos__list, u64 start, u64 len,
>  	if (self != NULL) {
>  		char newfilename[PATH_MAX];
>  		struct dso *dso;
> -		int anon;
> +		int anon, no_dso;
>  
>  		anon = is_anon_memory(filename);
> +		no_dso = is_no_dso_memory(filename);
>  
>  		if (anon) {
>  			snprintf(newfilename, sizeof(newfilename), "/tmp/perf-%d.map", pid);
> @@ -57,12 +65,16 @@ struct map *map__new(struct list_head *dsos__list, u64 start, u64 len,
>  
>  		map__init(self, type, start, start + len, pgoff, dso);
>  
> -		if (anon) {
> -set_identity:
> +		if (anon || no_dso) {
>  			self->map_ip = self->unmap_ip = identity__map_ip;
> -		} else if (strcmp(filename, "[vdso]") == 0) {
> -			dso__set_loaded(dso, self->type);
> -			goto set_identity;
> +
> +			/*
> +			 * Set memory without DSO as loaded. All map__find_*
> +			 * functions still return NULL, and we avoid the
> +			 * unnecessary map__load warning.
> +			 */
> +			if (no_dso)
> +				dso__set_loaded(dso, self->type);
>  		}
>  	}
>  	return self;
> -- 
> 1.7.4
> 

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

* Re: [PATCH] perf, tool: Treat all memory maps without dso file as loaded
  2011-09-29 16:11         ` Jiri Olsa
@ 2011-09-29 22:09           ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 7+ messages in thread
From: Arnaldo Carvalho de Melo @ 2011-09-29 22:09 UTC (permalink / raw)
  To: Jiri Olsa; +Cc: a.p.zijlstra, mingo, paulus, linux-kernel

Em Thu, Sep 29, 2011 at 06:11:03PM +0200, Jiri Olsa escreveu:
> > and here it is ;)
> 
> hi,
> any feedback?

I'm applying it now because the warning is annoying, but recently I
noticed that at least for vdso:


[admin@felicio x86_64]$ rpm -ql kernel-2.6.35.14-96.fc14 | grep vdso
/lib/modules/2.6.35.14-96.fc14.x86_64/vdso
/lib/modules/2.6.35.14-96.fc14.x86_64/vdso/vdso.so
/lib/modules/2.6.35.14-96.fc14.x86_64/vdso/vdso32-int80.so
/lib/modules/2.6.35.14-96.fc14.x86_64/vdso/vdso32-syscall.so
/lib/modules/2.6.35.14-96.fc14.x86_64/vdso/vdso32-sysenter.so
[admin@felicio x86_64]$ readelf -s /lib/modules/2.6.35.14-96.fc14.x86_64/vdso/vdso.so | head

Symbol table '.dynsym' contains 9 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: ffffffffff70030c     0 SECTION LOCAL  DEFAULT    7 
     2: ffffffffff700830   133 FUNC    WEAK   DEFAULT   12 clock_gettime@@LINUX_2.6
     3: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS LINUX_2.6
     4: ffffffffff7008c0   139 FUNC    GLOBAL DEFAULT   12 __vdso_gettimeofday@@LINUX_2.6
     5: ffffffffff700950    61 FUNC    GLOBAL DEFAULT   12 __vdso_getcpu@@LINUX_2.6
     6: ffffffffff7008c0   139 FUNC    WEAK   DEFAULT   12 gettimeofday@@LINUX_2.6
[admin@felicio x86_64]$ rpm -ql kernel-debuginfo | grep vdso
/usr/lib/debug/lib/modules/2.6.35.14-96.fc14.x86_64/vdso
/usr/lib/debug/lib/modules/2.6.35.14-96.fc14.x86_64/vdso/vdso.so.debug
/usr/lib/debug/lib/modules/2.6.35.14-96.fc14.x86_64/vdso/vdso32-int80.so.debug
/usr/lib/debug/lib/modules/2.6.35.14-96.fc14.x86_64/vdso/vdso32-syscall.so.debug
/usr/lib/debug/lib/modules/2.6.35.14-96.fc14.x86_64/vdso/vdso32-sysenter.so.debug
[admin@felicio x86_64]$ 

So eventually we need to remove "[vdso]" from that function and make it use the
symtabs above.

- Arnaldo

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

end of thread, other threads:[~2011-09-29 22:10 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-10 12:44 [PATCH] perf map: Do not display load warning for maps without dso Jiri Olsa
2011-08-22  7:53 ` Jiri Olsa
2011-08-22 14:11   ` Arnaldo Carvalho de Melo
2011-08-22 14:58     ` Jiri Olsa
2011-08-24 13:18       ` [PATCH] perf, tool: Treat all memory maps without dso file as loaded Jiri Olsa
2011-09-29 16:11         ` Jiri Olsa
2011-09-29 22:09           ` Arnaldo Carvalho de Melo

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.