Assembler errors when compiling nofib benchmarks with -optc-g
marlowsd at gmail.com
Tue Nov 3 05:26:04 EST 2009
On 02/11/2009 21:49, Henry DeYoung wrote:
> On Mon, November 2, 2009 9:09 am, Simon Marlow wrote:
>> On 31/10/2009 18:27, Henry DeYoung wrote:
>>> We've decided to use oprofile to sample cache misses recorded by the
>>> performance counters. To get reasonable information out of oprofile,
>>> like to compile the nofib benchmarks via C with export of debugging
>>> As a first step toward this, I've changed the NoFibHcOpts variable in
>>> nofib/mk/boilerplate.mk to be:
>>> NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g
>> That won't work, I'm afraid. The Evil Mangler script that
>> post-processes the .s file output by gcc does not understand the debug
>> annotations added by gcc's -g flag.
>> The best you can do with oprofile is get assembly-level profiling. It's
>> not too bad actually; I've used it in the past myself, although oprofile
>> itself I found to be a bit flaky - for some reason it seems to stop
>> counting randomly on my laptop.
>> You might have better luck using the new performance counter support
>> ("performance events") in Linux 2.6.31. I've not been able to test it
>> yet myself because apparently it doesn't support the CPU in my laptop, but
>> I plan to find another machine to try it on soon.
> So now I'm using
> NoFibHcOpts = -O -keep-s-files -opta-g
> which seems to work fine. You mentioned that assembly-level profiling is
> the best you can do with oprofile (in particular). Is there another
> profiler that would allow source-level (in Haskell or the generated C
> code) profiling, or is this as good as it gets for any profiler since GHC
> doesn't seem to export debugging symbols at the source level?
This is as good as it gets, yes.
> Also, based on what you've heard, would you recommend the Linux 2.6.31
> performance counter tools over the PAPI library? (I see that there is
> PAPI support in the GHC runtime:
The main difficulty with PAPI is that it is so hard to get it working.
You need a patched kernel, and then building and installing PAPI itself
is not at all easy. If I was going to install it on a new machine, I'd
set aside a day to do it.
The new Linux performance events infrastructure will be in the default
kernel that comes with most distributions - Ubuntu Karmic includes it
for example. That makes it a lot more attractive for me. Also it has
support for annotating source (or assembly) with profiling results, like
oprofile. I don't think PAPI has that, but I could be wrong. On the
other hand, PAPI has an API for saving/restoring sets of counters, which
is what we use in GHC's RTS for separating the GC counters from the
mutator. I hope I'll be able to do that with perf events, but I don't
> Thanks so much for all your help!
More information about the Glasgow-haskell-users