Date: Thu, 11 Dec 2025 17:21:16 -0800 From: Steve Kargl <kargls@comcast.net> To: Mark Millard <marklmi@yahoo.com>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: profiling a user executable? Message-ID: <93bffe4f-7bb0-4ed0-9754-45dc485ac0fb@comcast.net> In-Reply-To: <A8D6D0EB-04A9-4EAF-B725-25424AD9E5AC@yahoo.com>
index | next in thread | previous in thread | raw e-mail
On 12/11/25 16:50, Mark Millard wrote: > Steve Kargl <kargls_at_comcast.net> wrote on > Date: Thu, 11 Dec 2025 18:13:27 UTC : > >> In the days of yore, one could add the '-pg' option to >> the compilers options to generate profiling information, >> which could be consumed by gprof(1). >> >> FreeBSD stopped shipping libc_p.a, libm_p.m, etc >> (disabled in fe52b7f60ef4 and deleted in 3750ccefb8). >> This breaks all lang/gcc* ports if one uses '-pg'. It is >> not too difficult to fix lang/gcc* to avoid the missing >> *_p.a files, but this seems to lead to invalid *.gmon files. >> At least, for a Fortran application that I would like to >> profile (compiled with gfortran), procedures in my libfoo_p.a, >> appear in the profile, which I know with 100% certainty are >> not referenced. >> >> So, how does one in modern FreeBSD, as mere normal user, >> profile an executable? A google search suggests pmcstat(8) >> may be of use, but all attempts to use it lead to a usage >> message printed to the terminal. I'm simply trying to >> determine where my code is spending all of its time. > > The below may or may not be sufficient for your > purposes. (Also, my context has a root login for > this. I've not tested non-root use.) > > The below starts after I'd already done: > > # kldload hwpmc > > > ) Example starting commands: > > # pmcstat -O pmc.O -P ex_ret_instr openssl speed > > or: > > # pmcstat -O pmc.O -P ls_not_halted_cyc openssl speed > > [Note: aarch64 uses different names than ex_ret_instr > and ls_not_halted_cyc for somewhat analogous event > types. Also, .O is likely not the normal naming but I > matched the letter to the command line option during > my explorations.] > > -P is for process sampling. (There is also -S for > System sampling.) It is followed by the name of an > event type that will sometimes lead to a sample being > taken. (retired instructions and non-halted cpu cycles > examples are listed above.) Thanks. Understanding the various event types is likely the root of my issues. I'll see what 'pmccontrol -L' yields on the two very different x86_64 systems I use. > ) Having produced the pmc.O then produce .gmon files: > > [Note the directory name below that resulted matches the > "ex_ret_instr" form of the pmcstat -P option that I used > as my example : retired instructions.] > > # pmcstat -R pmc.O -g > I definitely misunderstood how the -g option worked. I did realize that it is essentially as a post-processing option for a previous recorded file. -- stevehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93bffe4f-7bb0-4ed0-9754-45dc485ac0fb>