All of lore.kernel.org
 help / color / mirror / Atom feed
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


      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.