Assembler errors when compiling nofib benchmarks with -optc-g

[Simon Marlow]

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,
>>> I'd
>>> like to compile the nofib benchmarks via C with export of debugging
>>> symbols.
>>>
>>> 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:
> http://hackage.haskell.org/trac/ghc/wiki/PAPI)

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 
know yet.

> Thanks so much for all your help!

Cheers,
	Simon