* Symbols not decoded in 0.0.2.PERF
@ 2011-04-19 11:22 Johan Tibell
2011-04-19 15:58 ` Johan Tibell
0 siblings, 1 reply; 3+ messages in thread
From: Johan Tibell @ 2011-04-19 11:22 UTC (permalink / raw)
To: linux-perf-users
Hi,
I'm trying to use perf record/report on a non-stripped, Haskell binary
(i.e. compiled using GHC). Unfortunately, not all symbols are
decoded*:
75.28% bench ./bench [.] 0x000000002b612b
7.11% bench /lib/libc-2.11.1.so [.] memcpy
5.47% bench ./bench [.] 0x0000000000438f
3.47% bench ./bench [.] allocate
1.86% bench ./bench [.] s1Ol_info
1.65% bench ./bench [.] s1Ok_info
0.62% bench ./bench [.] memcpy@plt
0.48% bench ./bench [.] clearNurseries
0.33% bench ./bench [.] evacuate1
0.24% bench ./bench [.] GarbageCollect
How can I figure out what 0x000000002b612b corresponds to?
perf version: 0.0.2.PERF (installed from Ubuntu package)
Kernel version: 2.6.32
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
* It could be the case that GHC is generating symbols that perf cannot
interpret somehow. If we can confirm this is the case we can try to
fix that.
-- Johan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Symbols not decoded in 0.0.2.PERF
2011-04-19 11:22 Symbols not decoded in 0.0.2.PERF Johan Tibell
@ 2011-04-19 15:58 ` Johan Tibell
2011-04-20 8:55 ` Johan Tibell
0 siblings, 1 reply; 3+ messages in thread
From: Johan Tibell @ 2011-04-19 15:58 UTC (permalink / raw)
To: linux-perf-users
On Tue, Apr 19, 2011 at 1:22 PM, Johan Tibell <johan.tibell@gmail.com> wrote:
> * It could be the case that GHC is generating symbols that perf cannot
> interpret somehow. If we can confirm this is the case we can try to
> fix that.
I spent the day making sure this is not the case. All the Haskell
functions now have the correct (fingers crossed) .type and .size ELF
directives:
74.18% bench ./bench [.] 0x000000002ac524
7.19% bench /lib/libc-2.11.1.so [.] memcpy
4.53% bench ./bench [.] s1Ok_info
4.28% bench ./bench [.] s1Ol_info
3.28% bench ./bench [.] allocate
0.74% bench ./bench [.] Main_zdwa_info
0.62% bench ./bench [.] memcpy@plt
0.45% bench ./bench [.] clearNurseries
0.36% bench ./bench [.] evacuate
0.27% bench ./bench [.] stg_newArrayzh
Entries 3-6 and 8-10 are Haskell functions. The top entry is still unknown.
If it matters, the little program I'm running stresses array copying
and I would expect it to spend most of its time in memcpy, but these
numbers suggests that it isn't. Could it be some stripped C libraries
or some code generated by gcc specially for memcpy that's accounting
for the top entry?
Johan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Symbols not decoded in 0.0.2.PERF
2011-04-19 15:58 ` Johan Tibell
@ 2011-04-20 8:55 ` Johan Tibell
0 siblings, 0 replies; 3+ messages in thread
From: Johan Tibell @ 2011-04-20 8:55 UTC (permalink / raw)
To: linux-perf-users
On Tue, Apr 19, 2011 at 5:58 PM, Johan Tibell <johan.tibell@gmail.com> wrote:
> On Tue, Apr 19, 2011 at 1:22 PM, Johan Tibell <johan.tibell@gmail.com> wrote:
>> * It could be the case that GHC is generating symbols that perf cannot
>> interpret somehow. If we can confirm this is the case we can try to
>> fix that.
>
> I spent the day making sure this is not the case. All the Haskell
> functions now have the correct (fingers crossed) .type and .size ELF
> directives:
Problem solved. There were indeed some functions that didn't have any
.size directives, making perf (or is that objdump?) fail to recognize
the symbols.
Sorry for the noise.
Johan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-04-20 8:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-19 11:22 Symbols not decoded in 0.0.2.PERF Johan Tibell
2011-04-19 15:58 ` Johan Tibell
2011-04-20 8:55 ` Johan Tibell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).