Profiling C application

[Andrea Venturoli]

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.

[Scott Bennett via freebsd-questions]

Post by Andrea Venturoli

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
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 ...
% ./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
ldd 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.

Actually, I think it should work even using non-profiling libraries, but
you wouldn't see any data gathered regarding calls within those libraries.

Post by Andrea Venturoli
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"?

See above.
I am afraid I can be of little help. The last time I recall playing with
this stuff was under 4.3BSD or maybe SunOS 4.2. Either way it was with a now-
ancient compiler and set of libraries, not one used today. Now, thirty-odd
years later, I remember nothing much about it. My apologies to you.
Two questions occur to me. Have you tried using gcc/g++ as a test? Have
you tested it on a C program instead of a C++ program?

Scott

[Andrea Venturoli]

Post by Scott Bennett via freebsd-questions
I am afraid I can be of little help.

No problem.
I was convinced that this would not work; I just tried for the records,
since you said it should.
I'm using valgrind-devel for getting the job done.

Post by Scott Bennett via freebsd-questions
My apologies to you.

No problem, really.

Post by Scott Bennett via freebsd-questions
Two questions occur to me. Have you tried using gcc/g++ as a test? Have
you tested it on a C program instead of a C++ program?

No, I didn't.



bye & Thanks
av.