All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: a.p.zijlstra@chello.nl, mingo@elte.hu, paulus@samba.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf map: Do not display load warning for maps without dso
Date: Mon, 22 Aug 2011 11:11:30 -0300	[thread overview]
Message-ID: <20110822141130.GA21345@ghostprotocols.net> (raw)
In-Reply-To: <20110822075322.GI2073@jolsa.brq.redhat.com>

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];

  reply	other threads:[~2011-08-22 14:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110822141130.GA21345@ghostprotocols.net \
    --to=acme@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.