Date: Sun, 14 Dec 2025 21:55:16 -0800 From: Mark Millard <marklmi@yahoo.com> To: kargls@comcast.net, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: profiling a user executable? Message-ID: <12053856-4DE5-4B98-9309-028869BB5395@yahoo.com> References: <12053856-4DE5-4B98-9309-028869BB5395.ref@yahoo.com>
index | next in thread | previous in thread | raw e-mail
Steve Kargl <kargls_at_comcast.net> wrote on
Date: Sat, 13 Dec 2025 20:12:12 UTC :
> On 12/12/25 14:14, Ahmad Khalifa wrote:
> > On Thu Dec 11, 2025 at 8:13 PM +0200, Steve Kargl wrote:
> >> 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.
> >
> > Just throwing in another option, you can use dtrace's profile-n probes.
> >
>
> dtrace appears to be a useless for a mere user.
>
> % dtrace -n 'profile-99 /execname == "../../build/bin/tier -q"/ \
As I remember, execname holds only the base name that had been given
to exec for the current thread/process. Also, it is not a way to run
a program. It is a way to select processes/threads that are running
a known-base-name of interest. It is DTrace variable in specific
probes, not all probes.
As I remember, dtrace uses -c COMMAND notation to run the command
and exit once that command completes.
Trying to deal with paths is much more involved and can involve things
like copyinstr(arg0) notation, arg0 being for the first argument to the
probe as the example.
DTrace normally requires privileges: root, or role-based, or granting
dtrce_proc (allow tracing of processes owned), dtrace_user, or
dtrace_kernel . (I've only actually used root style in my rare dtrace
usage.)
> { @[ustack()] = count(); }'
> dtrace: failed to initialize dtrace: DTrace requires
> additional privileges
>
> Interestingly, dtrace(1) seems to lack a discussion about privilege.
> At least, 'man dtrace' with a search on 'priv' and 'group' reveals
> nothing useful.
===
Mark Millard
marklmi at yahoo.com
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12053856-4DE5-4B98-9309-028869BB5395>