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

             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.