From owner-freebsd-current Thu Oct 24 00:49:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA22892 for current-outgoing; Thu, 24 Oct 1996 00:49:35 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA22887 for ; Thu, 24 Oct 1996 00:49:30 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id RAA02128; Thu, 24 Oct 1996 17:44:13 +1000 Date: Thu, 24 Oct 1996 17:44:13 +1000 From: Bruce Evans Message-Id: <199610240744.RAA02128@godzilla.zeta.org.au> To: bde@zeta.org.au, sgk@troutmask.apl.washington.edu Subject: Re: Is profiling code broken? Cc: freebsd-current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I recompiled my kernel with freshly supped sources and the problem >went away. The old kernel with the problem was built from sources >dated 9 Oct 96. What is strange about the situation is that I ran >some profiled code last week without a problem. The only things I I think it was (is) a hardware problem. >One other question: during a make world the profiled libraries are >built with the -p compiler option. Shouldn't this be -pg? Each time >I try to link an executable compiled with -p, ld complains about >/usr/lib/mcrt0.o missing. It makes no difference except for linking. If it made a difference, then I think -p might require more code than -pg, so it is reasonable for -p to be the default for libraries (another set of libraries would be too many). The extra code might be for per-function counters and possibly code to increment the counters. For gprof, the counters are allocated together with information about the call graph because separate counters would have small or negative benefits. I removed the generation of the separate counters from gcc a long time ago. They just wasted space (and time to pass pointers to them) because gprof didn't use them and we didn't have gprof. Bruce