From: "Dr. David Alan Gilbert" <linux@treblig.org>
To: linux-kernel@vger.kernel.org
Subject: perf: confused by cc1
Date: Thu, 31 Dec 2009 01:47:14 +0000 [thread overview]
Message-ID: <20091231014714.GA8313@gallifrey> (raw)
Hi,
I'm running 2.6.33rc2 and thought I'd have a play with perf; its
symbol resolution code seems to be getting itself a bit confused however:
I recorded a trace of a kernel build like so:
sudo /discs/more/git/linux-2.6/tools/perf/perf record -a -e cycles -i -g -v -s -d make -j 8 bzImage
Then I did:
/discs/more/git/linux-2.6/tools/perf/perf report -g
and the top entry is:
69.89% cc1 cc1 [.] 0x000000000337cd
|
|--0.99%-- 0x9f5da8
|
|--0.74%-- 0x9eec95
--98.27%-- [...]
but it's refusing to do symbol look up for cc1 even if I install
the (ubuntu) debug packages (most other files it is doing
symbol resolution on where they have it). I dug a bit further and
it looks like it's not trying to look up the debug packages for cc1
because it think that mapping is a kernel map. Also for some reason it
thinks the cc1 is an overlapping mapping with the gcc4 binary it's been
executed from:
DAG: thread__find_addr_location : /usr/bin/gcc-4.4 addr 0x402f98
DAG: map__find_symbol for /usr/bin/gcc-4.4
(anything starting DAG is something I've added)
{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}
0x68270 [0x20]: event: 7
.
. ... raw event: size 32 bytes
. 0000: 07 00 00 00 00 00 20 00 f7 54 00 00 f3 54 00 00 ...... ..T...T.
. 0010: f7 54 00 00 f3 54 00 00 bc 75 1c 9c 52 0c 00 00 .T...T...u..R..
.
0x68270 [0x20]: PERF_RECORD_FORK(21751:21751):(21747:21747)
0x68290 [0x18]: event: 3
.
. ... raw event: size 24 bytes
. 0000: 03 00 00 00 00 00 18 00 f7 54 00 00 f7 54 00 00 .........T...T.
. 0010: 63 63 31 00 00 00 00 00 .T...T.
.
0x68290 [0x18]: PERF_RECORD_COMM: cc1:21751
0x682a8 [0x50]: event: 1
.
. ... raw event: size 80 bytes
. 0000: 01 00 00 00 00 00 50 00 f7 54 00 00 f7 54 00 00 ......P..T...T.
. 0010: 00 00 40 00 00 00 00 00 00 90 83 00 00 00 00 00 ..@............
. 0020: 00 00 00 00 00 00 00 00 2f 75 73 72 2f 6c 69 62 ......../usr/li
. 0030: 2f 67 63 63 2f 78 38 36 5f 36 34 2d 6c 69 6e 75 /gcc/x86_64-lin
. 0040: 78 2d 67 6e 75 2f 34 2e 34 2f 63 63 31 00 00 00 x-gnu/4.4/cc1..
.
0x682a8 [0x50]: PERF_RECORD_MMAPDAG: map__new for /usr/lib/gcc/x86_64-linux-gnu/4.4/cc1
21751/21751: [0x400000(0x839000) @ (nil)]: /usr/lib/gcc/x86_64-linux-gnu/4.4/cc1
DAG: thread__insert_map: 400000-c39000 0 /usr/lib/gcc/x86_64-linux-gnu/4.4/cc1
overlapping maps:
400000-c39000 0 /usr/lib/gcc/x86_64-linux-gnu/4.4/cc1
400000-43c000 0 /usr/bin/gcc-4.4
0x682f8 [0x40]: event: 1
{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}
.....and then when it gets an event in cc1:
{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}
0x684f8 [0x40]: event: 9
.
. ... raw event: size 64 bytes
. 0000: 09 00 00 00 02 00 40 00 23 dc 64 00 00 00 00 00 ......@.#.d....
. 0010: f7 54 00 00 f7 54 00 00 00 00 00 00 00 00 00 00 .T...T.........
. 0020: 6c 23 2a 00 00 00 00 00 02 00 00 00 00 00 00 00 l#*............
. 0030: 00 fe ff ff ff ff ff ff 23 dc 64 00 00 00 00 00 ........#.d....
.
0x684f8 [0x40]: PERF_RECORD_SAMPLE(IP, 2): 21751/21751: 0x64dc23 period: 2761580
... chain: nr:2
..... 0: fffffffffffffe00
..... 1: 000000000064dc23
... thread: cc1:21751
DAG: thread__find_addr_location : /usr/lib/gcc/x86_64-linux-gnu/4.4/cc1 addr 0x64dc23
DAG: map__find_symbol for /usr/lib/gcc/x86_64-linux-gnu/4.4/cc1
DAG: map__load: for /usr/lib/gcc/x86_64-linux-gnu/4.4/cc1 kernel=1
DAG: dso__load: Called for /usr/lib/gcc/x86_64-linux-gnu/4.4/cc1 self->kernel=1
Looking at the vmlinux_path (5 entries long)
symbol__new: bad_address 0xffffffff8100019a-0xffffffff8100019a
{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}{--}
I haven't yet found why kernel=1 is set for cc1, but I assume it's fallout
from whatever reason that it's failed to understand the exec of cc1
and deal with the overlap.
(On Ubuntu Lucid alpha on an Intel i7)
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
next reply other threads:[~2009-12-31 1:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-31 1:47 Dr. David Alan Gilbert [this message]
2009-12-31 3:10 ` perf: confused by cc1 Xiao Guangrong
2009-12-31 12:19 ` Dr. David Alan Gilbert
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=20091231014714.GA8313@gallifrey \
--to=linux@treblig.org \
--cc=linux-kernel@vger.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.