From: David Ahern <dsahern@gmail.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
LKML <linux-kernel@vger.kernel.org>,
Irina Tirdea <irina.tirdea@gmail.com>
Subject: Re: why is perf-report asking for objdump path?
Date: Thu, 01 Nov 2012 21:37:31 -0600 [thread overview]
Message-ID: <50933FFB.8060300@gmail.com> (raw)
In-Reply-To: <87sj8s4xlt.fsf@sejong.aot.lge.com>
On 11/1/12 7:11 PM, Namhyung Kim wrote:
> From f0a9d6303f83452c8b6f81081abae8fdf9c81778 Mon Sep 17 00:00:00 2001
> From: Namhyung Kim<namhyung.kim@lge.com>
> Date: Fri, 2 Nov 2012 09:48:17 +0900
> Subject: [PATCH] perf tools: Use normalized arch name for searching objdump
> path
>
> David reported that perf report for i686 target data on x86_64 host
> failed to work because it tried to find out cross-compiled objdump.
>
> However objdump for x86_64 is compatible to i686 so that it doesn't
> need to do it at all. To prevent similar artifacts, normalize arch
> name when comparing host and file architectures.
>
This fixes the i686 perf.data file analyzed on x86_64. I don't have time
for the reverse - partly because I needed to verify my other point on
this bug report: why does objdump path matter for non-annotate commands?
Before this patch I can analyze 32-bit ppc files on x86 (an important
use case on my end). After the objdump patch it fails -- or rather, I
have to add the --objdump argument which is awkward. I don't want to
have to educate users to add a non-sensical argument to perf-report (and
other specialized commands).
David
prev parent reply other threads:[~2012-11-02 3:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-01 21:09 why is perf-report asking for objdump path? David Ahern
2012-11-02 1:11 ` Namhyung Kim
2012-11-02 3:37 ` David Ahern [this message]
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=50933FFB.8060300@gmail.com \
--to=dsahern@gmail.com \
--cc=acme@ghostprotocols.net \
--cc=irina.tirdea@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@kernel.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.