Profiling C application

[Andrea Venturoli]

On 11/29/20 1:02 PM, Scott Bennett wrote:
> Andrea Venturoli <ml at netfence.it> wrote:
> 
>> On 11/28/20 8:22 PM, Scott Bennett via freebsd-questions wrote:
>>
>>>        I see you already have one response at least to your question, but
>>> perhaps a simpler one is to use a now ancient BSD UNIX tool called gprof(1),
>>> along with the compiler option -pg.  (See the gprof(1) man page for the
>>> details.)  Note, too, that you may want to link your program to the profiling
>>> versions of system libraries as explained in the man page.
>>
>> I didn't mention gprof because it stopped working when FreeBSD switched
>> from GCC to clang. Or, maybe, it was my fault, not being able to get it
>> working again.
>>
>> That was a long time ago, however; if nowadays it's a viable solution,
>> I'm happy to hear this.
>>
>       Bugzilla only turned up one PR that may have a bearing on that.  See
> PR 198462 from 2017 and 10.1.  There's no sign that anyone, other than the poster
> of the PR, even looked into it, an unfortunately common situation.
>       Thank you for pointing out the problem.  Do you still have a test case you
> could try?

Sorry for answering so late...

Today I need once again to profile a program and, since valgrind is 
currently broken :-(, I decided to give gprof another shot (on 12.2/amd64).

As per gprof(1), I added "-pg" to compilation and linking phase, i.e. my 
program compiles with something like:
c++ -c -ggdb -O0 -pg ... -o a.o a.cxx
c++ -c -ggdb -O0 -pg ... -o b.o b.cxx
...
c++ -o a.exe a.o b.o ... -lthr -pg ...

When I run it, I get:
% ./a.exe
ld-elf.so.1: /lib/libc.so.7: Undefined symbol "__progname"

gprof(1) states that "The -pg option also links in versions of the 
library routines that are compiled for profiling". Alas, this does not 
seem to be the case:
ldd a.exe
a.exe:
	libarchive.so.13 => /usr/local/lib/libarchive.so.13 (0x8004a0000)
	libboost_filesystem.so.1.72.0 => 
/usr/local/lib/libboost_filesystem.so.1.72.0 (0x800574000)
	libboost_program_options.so.1.72.0 => 
/usr/local/lib/libboost_program_options.so.1.72.0 (0x800591000)
	libboost_system.so.1.72.0 => /usr/local/lib/libboost_system.so.1.72.0 
(0x8005f1000)
	libcrypto.so.111 => /lib/libcrypto.so.111 (0x8005f5000)
	libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x8008e7000)
	liblzo2.so.2 => /usr/local/lib/liblzo2.so.2 (0x800914000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x800944000)
	liblz4.so.1 => /usr/local/lib/liblz4.so.1 (0x800970000)
	libbz2.so.4 => /usr/lib/libbz2.so.4 (0x80099e000)
	libz.so.6 => /lib/libz.so.6 (0x8009b4000)
	libc.so.7 => /lib/libc.so.7 (0x8009d0000)
	libc++.so.1 => /usr/lib/libc++.so.1 (0x800dc6000)
	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800e93000)
	libm.so.5 => /lib/libm.so.5 (0x800eb5000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800ee7000)
	libthr.so.3 => /lib/libthr.so.3 (0x800f01000)
	libmd.so.6 => /lib/libmd.so.6 (0x800f2e000)

I think I should change "-lthr" to "-lthr_p", but that does not make any 
difference. Ditto if I add "-lc_p": apparently these are ignored.

What am I doing wrong?

BTW, would solving this be enough or would I later hit the fact that I'm 
using third party libraries (e.g. boost) which are not compiled with "-pg"?

  bye & Thanks
	av.