|
From: <stu...@nu...> - 2010-10-11 02:32:41
|
Hi, I am running valgrind 3.4.1 on a ppc32 system, using uClibc. I am using 3.4.1 because 3.5.0 won't compile for ppc32. I am running a multi-threaded program under callgrind, viewing the call graph in kcachegrind. The output looks reasonably sane, up to a point. But if I turn off cycle detection in kcachegrind, I see some function calls which just don't make sense (e.g. fprintf calling one of my application's functions). If I turn cycle detection on, almost all of the cycles seem to get folded up into a nameless call labelled as "<cycle 2>" in libpthread.so This leads me to believe that the call graph is getting befuddled by pthread context switches. Is this a fair assumption? Is it a known problem? Is there anything I can do about it? Thanks very much, Stuart ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
|
From: Josef W. <Jos...@gm...> - 2010-10-11 18:20:19
|
Hi,
On Monday 11 October 2010, stu...@nu... wrote:
> I am running valgrind 3.4.1 on a ppc32 system, using uClibc. I am using
> 3.4.1 because 3.5.0 won't compile for ppc32.
Oh, what is the reason?
> I am running a multi-threaded program under callgrind, viewing the call
> graph in kcachegrind.
>
> The output looks reasonably sane, up to a point. But if I turn off cycle
> detection in kcachegrind, I see some function calls which just don't make
> sense (e.g. fprintf calling one of my application's functions).
Yes, it is known that Callgrind sometimes is completely wrong regarding calls
and returns on PPC{32/64}, as well as on the newly introduced ARM support in
the upcoming 3.6.0 (see bug 252091 for the ARM bug report,
https://bugs.kde.org/show_bug.cgi?id=252091).
The reason are some hardcoded assumptions which only are true on x86/amd64.
Can you open a similar bug report for PPC32 for this, describing the problems
you see?
It does not really have something to do with PThreads, as far as I can see.
Thanks,
Josef
>
> If I turn cycle detection on, almost all of the cycles seem to get folded
> up into a nameless call labelled as "<cycle 2>" in libpthread.so
>
> This leads me to believe that the call graph is getting befuddled by
> pthread context switches. Is this a fair assumption? Is it a known
> problem? Is there anything I can do about it?
>
> Thanks very much,
>
> Stuart
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
|
|
From: <stu...@nu...> - 2010-10-13 00:48:03
|
Hi Josef, Thanks very much for the reply. Comments below... > > I am running valgrind 3.4.1 on a ppc32 system, using uClibc. I am using > > 3.4.1 because 3.5.0 won't compile for ppc32. > > Oh, what is the reason? http://osdir.com/ml/kde-bugs-dist/2009-08/msg13796.html I have since tried using 3.6 from the TRUNK however, and I got the same problem. > Yes, it is known that Callgrind sometimes is completely wrong regarding calls > and returns on PPC{32/64}, as well as on the newly introduced ARM support in > the upcoming 3.6.0 (see bug 252091 for the ARM bug report, > https://bugs.kde.org/show_bug.cgi?id=252091). > > The reason are some hardcoded assumptions which only are true on x86/amd64. > > Can you open a similar bug report for PPC32 for this, describing the problems > you see? I will get a small sample program to behave badly, and then post it in a bug report. This sucks quite a bit, since callgrind is the only profiling solution available on my platform (gprof and orprofile won't work for various reasons). As I said however, the output from callgrind looks relatively sane. Am I a fool to rely on it as some sort of guide for optimisation work? In the meantime, I will work with the developers to get this fixed. Am happy to do dev work. It's very important to me that this be resolved. Thanks again, Stuart ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
|
From: Josef W. <Jos...@gm...> - 2010-10-13 08:48:35
|
On Wednesday 13 October 2010, stu...@nu... wrote: > Hi Josef, > > Thanks very much for the reply. Comments below... > > > > I am running valgrind 3.4.1 on a ppc32 system, using uClibc. I am > using > > > 3.4.1 because 3.5.0 won't compile for ppc32. > > > > Oh, what is the reason? > > http://osdir.com/ml/kde-bugs-dist/2009-08/msg13796.html Hmm.. this bug (204843) seems to be fixed since quite some time in SVN. > I have since tried using 3.6 from the TRUNK however, and I got the same > problem. > > > Yes, it is known that Callgrind sometimes is completely wrong regarding > calls > > and returns on PPC{32/64}, as well as on the newly introduced ARM > support in > > the upcoming 3.6.0 (see bug 252091 for the ARM bug report, > > https://bugs.kde.org/show_bug.cgi?id=252091). > > > > The reason are some hardcoded assumptions which only are true on > x86/amd64. > > > > Can you open a similar bug report for PPC32 for this, describing the > problems > > you see? > > I will get a small sample program to behave badly, and then post it in a > bug report. Thanks, very would be very good! > This sucks quite a bit, since callgrind is the only profiling solution > available on my platform (gprof and orprofile won't work for various > reasons). > > As I said however, the output from callgrind looks relatively sane. Am I > a fool to rely on it as some sort of guide for optimisation work? No, not at all. Self/exclusive costs should be perfectly fine. I just would not count to much on the inclusive cost numbers. > In the meantime, I will work with the developers to get this fixed. Am > happy to do dev work. It's very important to me that this be resolved. Yes, for me too, as the same issue arrises with the ARM support (to become part of SVN 3.6.0). Thanks, Josef > > Thanks again, > > Stuart > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ |