From nobody Mon Dec 15 07:18:32 2025 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dVBHj71flz6Kh8N for ; Mon, 15 Dec 2025 07:18:41 +0000 (UTC) (envelope-from kargls@comcast.net) Received: from resqmta-h2p-567354.sys.comcast.net (resqmta-h2p-567354.sys.comcast.net [IPv6:2001:558:fd02:2446::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dVBHj43Hzz3V4t for ; Mon, 15 Dec 2025 07:18:41 +0000 (UTC) (envelope-from kargls@comcast.net) Authentication-Results: mx1.freebsd.org; none Received: from resomta-h2p-554994.sys.comcast.net ([96.102.179.205]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resqmta-h2p-567354.sys.comcast.net with ESMTPS id V2k0vgvyY9hu8V2qnvIWET; Mon, 15 Dec 2025 07:18:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1765783113; bh=/C5kS3mnWppgXVlFQHueh3Al/aErDEQlmo8/pVSNOiY=; h=Received:Received:Message-ID:Date:MIME-Version:Subject:To:From: Content-Type:Xfinity-Spam-Result; b=hUT8god/44GRqS/OLTvUgibThxUwEJAmFhSPsyMuR3IzXreDn69zVOcIj7BhqCgEX jDG5A1sX4tWAdAOC39pJRdRnsAml5JMAnfqZEsBDAcawYlj1IdmuceKvKLX2OT0gp6 XVMB0NQByjQ4U73UGzdBgMvrPggP8hvWtXd96VavkYZnpxbKYx4/9+IPTNJ+lmri9p HGwYgqm9tHBSdPP1CElqScMfRjcxv7w3b1tgg0szdlKpE14oNYLxpW7o9bp5Ivr7+x zpSgVlmk5HPXYemMRPyYGWspMc01Db7ku7EaGmlnKrrAV7MNGNq3zyibXM2L1O179f i3qiih8JVw57Q== Received: from [10.0.0.30] ([73.97.237.216]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resomta-h2p-554994.sys.comcast.net with ESMTPSA id V2qmvQJTFZW4DV2qmv82hr; Mon, 15 Dec 2025 07:18:33 +0000 Message-ID: Date: Sun, 14 Dec 2025 23:18:32 -0800 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: profiling a user executable? To: Mark Millard , freebsd-hackers References: <12053856-4DE5-4B98-9309-028869BB5395.ref@yahoo.com> <12053856-4DE5-4B98-9309-028869BB5395@yahoo.com> Content-Language: en-US From: Steve Kargl In-Reply-To: <12053856-4DE5-4B98-9309-028869BB5395@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfBPTy+uNxGbdEWXeM4KzqiANGn68ef54OtLG0bjn/VR3sMA4NfFf48BF5orUSRd6b98039wFJcsvXmYu8bC0gbaQvGbZZNe99+ZjHMbRkhLfO9QMEXJW antDhZ+U0nt9uWAKSmrMZbT9kx4Hf8XDObY0ga0OLwsEI9VLwqhwzqAMywwa2C9n0ayyyaTj7k/G2sbPoae4PAEwu6+0jtCEDk5rdotxObryxq9PZMZiXUVL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dVBHj43Hzz3V4t On 12/14/25 21:55, Mark Millard wrote: > Steve Kargl 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. > Unfortunately, dtrace requires root privilege, and so is a non-starter. I adapted your suggestions with pmcstat to my problem, and it seems promising. % pmcstat -O pmc.0 -P ex_ret_instr ../../build/bin/tier -q % pmcstat -R pmc.0 -g % gprof ../../build/bin/tier ex_ret_instr/tier.gmon | head -10 | tail -8 Each sample counts as 0.0078125 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 36.68 13.15 13.15 13192 1.00 1.75 __spherem_MOD_sphere 23.06 21.41 8.27 __pnam_MOD_pna_dble 16.85 27.45 6.04 2045 2.95 3.00 __sjnm_MOD_sjn_dble 10.08 31.07 3.61 693 5.21 5.34 __synm_MOD_syn_dble 8.02 33.94 2.88 __sjnm_MOD_sjn_sngl I know with 100% certainty that __sjnm_MOD_sjn_sngl is not referenced in the code as I wrote it. I'll note the above is similar to what 'gfortran -pg' produces. % pmcstat -R pmc.0 -G zxc.graph CONVERSION STATISTICS: #exec/elf 1 #samples/total 67133 #samples/unknown-function 1775 #callchain/dubious-frames 17 % grep sjn_dble zxc.graph | wc -l 258 % grep sjn_sngl zxc.graph | wc -l 0 The callgraph shows that __sjnm_MOD_sjn_sngl is not used. My working conclusion is that gprof is simply broken. I'm still investigating what pmcstat can given me. Given the attempt to convert to a gprof file, hopefully I can get something like % pmcstat -R pmc.0 [some option(s)] cycles cycles/cal function 10000 90 __spherem_MOD_sphere 12345 191 __pnam_MOD_pna_dble 5433 400 __sjnm_MOD_sjn_dble 15000 1500 __synm_MOD_syn_dble This would tell me which routine(s) to look into for optimizations. -- steve