Profiling support

[Tim Van Holder]

Torsten Bonde Christiansen wrote:
> Adding function foo() does indeed show up as being called once in the 
> program. Details listed here:
> http://pastebin.com/f5f45b3f2
>> (Now that GMP is used by GCC 4.3, my diatribes about GCC bugs might
>> backfire.  A bug in GMP might cause GCC to miscompile things, e.g.,
>> GMP...)
>>
>>   
> And ldd a.out shows:
> mcbain at bellini:~/tmp$ ldd a.out
>         libgmp.so.3 => /usr/local/lib/libgmp.so.3 (0x00002b528fcd3000)
>         libc.so.6 => /lib/libc.so.6 (0x00002b528ff22000)
>         /lib64/ld-linux-x86-64.so.2 (0x00002b528fab5000)
> 
> 
> Still no clue to whats wrong.

Things to try:
1) Link with the static version of the library - perhaps the profiling
    support does not follow dynamic links.
2) Make a dummy .so of your own containing e.g. that foo() function;
    then see if foo() is still profiled as called once.
3) Do an objdump on your main.o (the one compiled with -pg) - if it
    shows any sections or symbols that strongly indicate they're intended
    for profiling (compare with a version of main.o compiled without
    -pg), check to see if those sections/symbols are also present in the
    GMP library. If not, check to see if they're present in the objects
    created during the GMP build (they might be getting stripped out in
    the linking process).
4) This is a real longshot, but do an strace on your test program -
    perhaps the .so is, for some ungodly reason, sending profiling output
    to a separate gmon.out file.

If none of those shed any light on the matter, I'm afraid I'll have to 
join Torbjorn in throwing my hands up and declaring myself unable to assist.
If step 2) does not show foo() in the profiling output, you may need to 
try to get some answers on a GCC list, because then it certainly 
suggests a problem with the build system.