[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52554F5E.2090200@intel.com>
Date: Wed, 09 Oct 2013 15:43:10 +0300
From: Adrian Hunter <adrian.hunter@...el.com>
To: Jiri Olsa <jolsa@...hat.com>
CC: Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
linux-kernel@...r.kernel.org, David Ahern <dsahern@...il.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Mike Galbraith <efault@....de>,
Namhyung Kim <namhyung@...il.com>,
Paul Mackerras <paulus@...ba.org>,
Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH V5 3/9] perf tools: workaround objdump difficulties with
kcore
On 09/10/13 15:16, Jiri Olsa wrote:
> On Wed, Oct 09, 2013 at 01:38:04PM +0300, Adrian Hunter wrote:
>> On 09/10/13 13:12, Jiri Olsa wrote:
>>> On Wed, Oct 09, 2013 at 10:33:25AM +0300, Adrian Hunter wrote:
>>>> On 08/10/13 17:02, Jiri Olsa wrote:
>>>>> On Tue, Oct 08, 2013 at 11:45:50AM +0300, Adrian Hunter wrote:
>
> SNIP
>
>>>
>>> so.. the name of the section, name of the <function> plus the first
>>> instruction decode seem wrong.. I can see that in every symbol I
>>> annotate in the report and in annotate command as well.
>>
>> If you use the --asm-raw option you can see the bytes:
>>
>> 66 66 66 90
>>
>> That looks like a "nop" e.g. K8_NOP4 in arch/x86/include/asm/nops.h
>>
>
> hum, wierd for all those functions to start with nop
I guess it is for ftrace.
>
> ok, how about the '<load0>' function name?
That is because kcore (and its copies) have no symbols
so objdump has nothing meaningful to put there. The function
name and file appear at the top of the screen instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists