linux-kernel - Re: perf: cannot resolve kernel symbols

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 23 Sep 2013 09:43:33 +0200
From:	Jean Pihet <jean.pihet@...aro.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	".Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Subject: Re: perf: cannot resolve kernel symbols

Hi Namhyung,

On 23 September 2013 08:58, Namhyung Kim <namhyung@...nel.org> wrote:
> Hi Jean,
>
> On Thu, 19 Sep 2013 15:24:56 +0200, Jean Pihet wrote:
>> Hi,
>>
>> Ping on this issue. Any idea or pointer.
>
> Did you build perf without libelf?
no, libelf is linked to the binary.
What is weird is that the same perf binary works ok with the distro
installed kernel and not with the self built and installed one.
I suspect something with the entries in ~/.debug/.build_id and
~/.debug/[kernel.kallsyms].

Thanks,
Jean

>
> Thanks,
> Namhyung
>
>>
>> Cheers,
>> Jean
>>
>> On 17 September 2013 14:02, Jean Pihet <jean.pihet@...aro.org> wrote:
>>> Hi,
>>>
>>> I am running the perf record and report commands, which are running OK
>>> but I do not get any kernel symbol resolved when using a built and
>>> installed kernel.
>>> Using the distro installed kernel is OK though.
>>> The setup is: Marvell ARMv7 quad core, Linaro Ubuntu release.
>>>
>>> Here are the commands in use:
>>> - perf record -g dwarf -- stress --cpu 2 --io 2 --vm 2 --timeout 1s
>>> - perf report -vvv
>>>
>>> With a vmlinux found at /lib/modules/<version>/build I get the
>>> following in the trace output:
>>> ...
>>> Looking at the vmlinux_path (6 entries long)
>>> Using /lib/modules/3.11.0-00003-g0d4d4a1/build/vmlinux for symbols
>>> ...
>>> dso: [kernel.kallsyms]
>>> (/lib/modules/3.11.0-00003-g0d4d4a1/build/vmlinux, Functions, loaded,
>>> 0000000000000000000000000000000000000000)
>>>  c00081c0-c00081c3 g asm_do_IRQ
>>> ...
>>> dso: [kernel.kallsyms].head.text ([kernel.kallsyms], Functions, loaded, 00000000
>>> 00000000000000000000000000000000)
>>>  c0008000-c0008077 g stext
>>>  c0008000-c0008000 g _text
>>>  c0008084-c0008127 l __create_page_tables
>>> ...
>>> dso: [kernel.kallsyms].init.text ([kernel.kallsyms], Functions, loaded, 00000000
>>> 00000000000000000000000000000000)
>>>  c04f3260-c04f32af l __fixup_smp
>>>
>>>
>>> Without any vmlinux found I get the following:
>>> ...
>>> Looking at the vmlinux_path (6 entries long)
>>> Using /proc/kallsyms for symbols
>>> ...
>>> dso: [kernel.kallsyms] ([kernel.kallsyms], Functions, loaded,
>>> 0000000000000000000000000000000000000000)
>>>  0-beffffff l __vectors_start
>>> dso: [kernel.kallsyms] ([kernel.kallsyms], Variables, NOT loaded,
>>> 0000000000000000000000000000000000000000)
>>> dso: stress (/usr/bin/stress, Functions, loaded,
>>> bdf57306ab106fb0ce9835c95dae5b173f238b61)
>>> ...
>>>
>>>
>>> In any case the symbols are not resolved although vmlinux contains
>>> symbols and /proc/kallsyms is accessible and working correctly.
>>> Any idea on where to look at? I guess the problem is in the kernel installation.
>>>
>>> Thx & regards,
>>> Jean
--
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/