Date: Thu, 08 Apr 2021 23:39:50 -0500 From: Scott Bennett <bennett@sdf.org> To: ml@netfence.it Cc: freebsd-questions@freebsd.org Subject: Re: Profiling C application Message-ID: <202104090439.1394dogG015985@sdf.org> In-Reply-To: <1139046c-7f48-dbdb-0790-bb821e9e9001@netfence.it> References: <202011281922.0ASJMtiH020409@sdf.org> <16423477-7854-20bf-58ff-c174375e37fe@netfence.it> <202011291202.0ATC2rbO024634@sdf.org> <1139046c-7f48-dbdb-0790-bb821e9e9001@netfence.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrea Venturoli <ml@netfence.it> wrote:
> On 11/29/20 1:02 PM, Scott Bennett wrote:
> > Andrea Venturoli <ml@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.
Actually, I think it should work even using non-profiling libraries, but
you wouldn't see any data gathered regarding calls within those libraries.
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202104090439.1394dogG015985>